While experts are present (and since the notes on security in the readme are refreshing), I'd like to ask a general question about securing OAuth 2 tokens.
My use case is to have a server that uses the explicit OAuth flow (redeeming a code obtained from the user in order to get permission to operate on the user’s behalf) but also have a front end client that uses the implicit flow (retrieving an access token for direct use) to make requests from the browser or mobile device. That way the user can surf freely and only hit the server when it needs to save something (which allows the app to scale).
The problem is that I don't want the user to have to authenticate twice. Ideally the user should be able to OK the standard OAuth web page to obtain a front end token AND also visit the server callback url with a redemption code. However I can’t find a single social provider that does this!
I scoured the web and Stack Overflow and can’t find a good discussion about the security of sharing tokens (all they say is to pass it over SSL). So the best I could come up with is to authenticate implicitly on the front end and pass the client access token to the server. This seems safer to me than sharing the explicit access token from the server to the client in the outside world.
Token sharing from client to server presents several security issues, because the server has to trust that the token belongs to the current user. It completely negates ever using the explicit flow, because most users are on mobile these days. The best the server can do is ask the social provider if the token’s app id matches the server’s app id, to prevent the confused deputy problem:
Believe it or not, several prominent social providers don’t even provide a token validation endpoint!
This whole experience has left me wary of OAuth 2 and I am concerned that it may not even be able to fulfill my very common use case. Am I completely missing something here? Thanks in advance for any insight you might provide.
5 comments
[ 3.3 ms ] story [ 25.0 ms ] threadMy use case is to have a server that uses the explicit OAuth flow (redeeming a code obtained from the user in order to get permission to operate on the user’s behalf) but also have a front end client that uses the implicit flow (retrieving an access token for direct use) to make requests from the browser or mobile device. That way the user can surf freely and only hit the server when it needs to save something (which allows the app to scale).
The problem is that I don't want the user to have to authenticate twice. Ideally the user should be able to OK the standard OAuth web page to obtain a front end token AND also visit the server callback url with a redemption code. However I can’t find a single social provider that does this!
I scoured the web and Stack Overflow and can’t find a good discussion about the security of sharing tokens (all they say is to pass it over SSL). So the best I could come up with is to authenticate implicitly on the front end and pass the client access token to the server. This seems safer to me than sharing the explicit access token from the server to the client in the outside world.
Token sharing from client to server presents several security issues, because the server has to trust that the token belongs to the current user. It completely negates ever using the explicit flow, because most users are on mobile these days. The best the server can do is ask the social provider if the token’s app id matches the server’s app id, to prevent the confused deputy problem:
http://blogs.mulesoft.com/dev/connectivity-dev/google-oauth-...
http://technotes.iangreenleaf.com/posts/closing-a-nasty-secu...
Believe it or not, several prominent social providers don’t even provide a token validation endpoint!
This whole experience has left me wary of OAuth 2 and I am concerned that it may not even be able to fulfill my very common use case. Am I completely missing something here? Thanks in advance for any insight you might provide.