OAuth Implementation & Security
mwarnerdotme opened this issue · comments
Hey everyone!
Sorry to open an issue for this... I didn't see that discussions were enabled on this repo, but I felt like I should address this concern regardless.
I noticed in the recent OAuth example (thanks @rphlmr) there was a particular file that caught my eye as a potential red flag. Keep in mind, I'm not an expert on OAuth, so please feel free to simply say that this is standard or at least acceptable.
In this example application's auth flow, we see a button being clicked which redirects to the social sign-in page which asks the user to Accept or Decline the OAuth and OIDC parameters. All standard and handled by Supabase: lovely! Then we redirect to the /oauth/callback route in the application, which effectively takes the access_token from the URL and sends it up to the server via an action. Also, we clean up our frontend Supabase context by calling supabaseClient.auth.signOut() since further DB requests and mutations will be handled by the server in accordance with the Remix philosophy.
Should these tokens, which are handed to the client by Supabase (this would be an implicit grant type token, right?), be sent from the client to the server this way? Does this break the OAuth standard or present any (major?) security risks? Would HTTPS be enough to cover the security question specifically?
P.S. Thanks for all of the hard work on this repo. We're all using a lot of new technology here and it feels wonderful to work with other devs who are pioneering new services and integrations.
Hello @mwarnerdotme 👋
First, I have to say that using supabaseClient.auth.signOut() was a mistake (Thanks jaPajaap).
The sample will be fix soon (2d96be0)
OAuth is almost always client side (never see a server side OAuth, but I don't know everything 😅).
The reason why server can't access the token in the provider's callback is explain here.
Short answer : it's related to the url fragment #access_token=xxxx (containing the token and other things). By design, browsers doesn't forward this to the server.
That's why we use supabase client in user land (we can also parse ourself the url and extract the token but I choose the simplicity).
Then, yes, the token is send to your action and it's secured by https like when you send your password in a form 😇
It's also as secure as the session cookie living in the browser (which contains the token).
NB: this token can be read on jwt.io because it's not crypt, only its content is signed to prevent client side modification using "secrets".
I hope my explanation is clear, not a native english writer 😬
I think that makes sense - the anchor fragment is not forwarded to the server by design because the access_token (and other sensitive info like the refresh_token) would be plain text in the url. So instead we extract it ourselves and send it in a request body, which is secured via HTTPS.
Your explanation is great! It's difficult to tell that you aren't native. Thanks for the quick response, and thanks again for your example.