How to properly use Client ID/Secret for browser applications?

[#1]

I'm relatively new to using OAuth. I'm developing a browser based web application and was wondering what the best way is to hide the client ID/secret. Obviously, I don't want to put those in the client code where anyone can view them. Right now, I have my javascript application directly call APIs on Edge with a username and password to request an access token. I can embed the client ID/secret on Edge and add them to any incoming requests. That way they aren’t exposed to the user. But it seems like any 3^rd party can still access my APIs. I’ve read that often they will be placed on a web server in between client requests and the Edge layer, but doesn’t this have the same problem as directly embedding the response on Edge? What’s the best way to use the client ID and secret?

[adas · Accepted solution]

@Hansford Hendargo very good question. Implementing OAuth for a client side app without a server component is alway challenging and exposes certain vulnerabilities depending on your app.

Here's a very interesting article about the same, which also talks about a proxy layer which is exactly what Edge is providing. Please take a look: http://alexbilbie.com/2014/11/oauth-and-javascript/

Let me know, if this makes sense and answers your question about OAuth and client side apps.

[#3]

Thank you for your response and the article link. If I understand it correctly, it sounds like this is similar to what we are already doing, as the Edge API itself adds the client ID/secret to the user's request for an access token, so it's already hidden on the proxy. One difference is that the article mentions sending encrypted cookies back to the user instead of the plain access token, which would require additional security measures, but that’s a slightly different problem dealing with hiding the access token.

Perhaps I’m not understanding the purpose of the clientID and secret. Is there actually any additional security provided by these? By putting the clientID and secret on the proxy, that information is hidden, but any requests coming to the proxy will have those automatically added in. So as long as an attacker calls that API, they would essentially already have those elements added in to their request and wouldn’t have to guess those, even if they can’t access them. The API is already secured by requiring a valid username and password, which if hacked obviously compromises the user. But it seems like the client ID and secret are not adding anything. What am I missing?

[DChiesa]

I don't think you're missing anything.

For more on this, you may wish to consult this Stackoverflow question, which asks, "Why is there an implicit grant type in Oauthv2.0?"

I particularly found this answer helpful. Summary is: Simplicity. With an in-browser Javascript app, users implicitly trust the app. There is no benefit of using the more complex flows. The client_id and secret are then identity of the JS app, not authentication.

> So as long as an attacker calls that API, they would essentially already have those elements added in to their request and wouldn’t have to guess those, even if they can’t access them.

Yes, on that point, that's the intent of the cookie that you mentioned previously. The cookie identifies a session, which we presume to have been established based on a user authentication or login. the cookie points to some data held on the server side that says who the user is, how they authenticated, when, etc. In that data you could also store a token.

helpful?

[#5]

I see. I think that makes sense. Thank you for your input!

[adas]

@Dino is absolutely right. That's why I said pure client side apps and OAuth 2.0 inherently have this problem or security risks depending on how paranoid you get regarding security. To provide additional security, you might want to validate the users credentials by letting them supply the username password, like in the example. But then again, you would need some backend as a service to provide that user datastore and authentication mechanism.

[akoo]

For completeness, I thought I'd chime in to address this question:

But it seems like any 3rd party can still access my APIs. I’ve read that often they will be placed on a web server in between client requests and the Edge layer, but doesn’t this have the same problem as directly embedding the response on Edge?

Assuming you are using auth code grant type, there is an intermediary called the authorization code that is available via a 302 redirect after the end-user authenticates. Ideally it is difficult to intercept the auth code because the connection between Edge and your login app is secured (TLS, VPN, IP whitelisted, etc.). The auth code is specific to a client_id, so there won't be an opportunity for confused deputy problem as with implicit grant type. Also, per IETF framework, the redirect URI, if provided during auth code minting, is validated against the redirect_uri param provided to generate the token-- Edge follows this as yet another check to avoid security holes.