37

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.

Community
  • 1
  • 1
machinery
  • 3,793
  • 4
  • 41
  • 52

2 Answers2

21

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

Kye
  • 4,279
  • 3
  • 21
  • 49
Eugenio Pace
  • 14,094
  • 1
  • 34
  • 43
4

In case of JS client, Google does validate that the JS origin matches the one registered with the client id. So if someone uses someone else's client id, at most they can get a token for only the accounts they own (which is not going to be very useful).

In general, you can never know who/what client (or code) is talking to your server. You only see the data they send. So if the same packets are sent by other clients/code, there is nothing you can do and in general you shouldn't care. You should care about that you have proper credentials in the request.

nvnagr
  • 2,017
  • 1
  • 14
  • 11