I'm new to OAuth2 and there's a problem I've been struggling with and despite research still can't grasp.
The difficulty in having a JS client for OAuth2 is that you can't store the client secret, because it will be widely accessible in the browser. I.e. in this SO question the highest-rated comment says:
"I think tokenSecret and consumerSekret parameters are supposed to be secret! How could they remain secret when downloaded to browser?!!!"
Therefore how do client-side OAuth2 frameworks like hello.js or oauth.io overcome this problem? I know they use a server-side proxy (which knows the ID and secret) for their requests, but the client JS code still needs to somehow tell the proxy who it is. So what prevents anyone from taking the JS code from my website and talking to the proxy on my behalf?
I've also found the Google APIs Client Library for JavaScript. AFAIK there the client code does not pass a secret. Do I understand correctly that they manage this by having a predefined OAuth response address? (so that the tokens are always returned via a predefined HTTP address). So even if somebody tries to impersonate my website by using my ID, the tokens will still get returned to my website?
Maybe I'm confusing a few different topics here, any light on the subject would be appreciated.
In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there is no user involved in the authentication.
OAuth2, uses the client secret mechanism as a means of authorizing a client, the software requesting an access token. You might think of it as a secret passphrase that proves to the authentication server that the client app is authorized to make a request on behalf of the user.
A standard for user authentication using OAuth: OpenID Connect. OpenID Connect is an open standard published in early 2014 that defines an interoperable way to use OAuth 2.0 to perform user authentication.
OAuth 2.0 is an authorization protocol and NOT an authentication protocol. As such, it is designed primarily as a means of granting access to a set of resources, for example, remote APIs or user's data.
There're flows in OAuth2 that don't require a secret (e.g. implicit
flow is typically used for JS based clients, SPAs, etc). Not all providers support this flow though, so in those situations you need a server side component that negotiates that for you and then handles the interactions with your front-end/device.
In any case, you need the user to authenticate. The secret
authenticates the client (your app), not the user. The return url (or callback) protects the token to be posted somewhere else (only your app).
Samples of these flows are here: https://docs.auth0.com/protocols#5
Update: There's a specific code/token exchange protocol for "public clients" that adds extra security: PKCE (how it works is here: https://auth0.com/docs/protocols#oauth2-pkce-for-public-clients)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With