8 ms·

> Add to that the fact that so many of the popular OAuth providers support "implicit grants" - where the access token is sent directly to the client - without a

> Add to that the fact that so many of the popular OAuth providers support "implicit grants" - where the access token is sent directly to the client - without adequate warning as to the security implications involved. Personally, I've yet to come across a case where the implicit flow is justified, and in my opinion, it should be disabled for any security-conscious OAuth provider (really, your fancy JS or mobile app can't communicate securely with a trusted server somewhere?). If you can't trust the client _just enough_ to let it have a bearer token, what can you trust it with to allow requests to any backend (yours or facebook's)? Cookies or a token for your backend will be just as comprimisable, with the sole advantage that the attacker now can only work via your API on behalf of that user. Furthermore, the devs taking shortcuts, if you take away implicit grants - guess what they'll do? They'll "encrypt" the client secret into their app, and pray that it's "good enough", then just emulate the code flow in the app. You're now less secure, because the OAuth provider is going to assume that the lack of implicit grant means "everyone is using a back end server", instead of being able to put tokens and clients into the "confidential" and "non-confidential" buckets. Non-opaque tokens I agree are probably bad. However, opaque tokens doesn't keep developers from taking shortcuts. Only well-written SDKs and libraries, either generalized (for all OAuth) or specialized (facebook SDK) can do that. I've spent enough time in reddit.com/r/redditdev to realize that a large majority of devs won't take the time to do it right - many barely understand how HTTP works, when they're first learning this stuff. There's so much to learn and understand that no one is going to get it right without significant help in the form of SDKs and libraries that just do the right thing by default.

dperfect 10y ago
Implicit grants are more dangerous for two reasons: (1) the process wherein the token is sent to the client can have serious security implications (especially for web apps) and (2) if your app communicates with any app-specific back end, the transfer of auth tokens between the app and back end is an additional temptation that is prone to have even more security issues. I do agree - if you have an app that is 100% client-side, and you're either using an official SDK or know what you're doing, implicit grants can be done securely (just as secure as any other bearer or session token, as you mention). The problem is that many app developers choose the implicit flow initially (because it's easier to implement), but then end up using it in ways that would be much better suited to the authorization grant flow.

dperfect 10y ago

Implicit grants are more dangerous for two reasons: (1) the process wherein the token is sent to the client can have serious security implications (especially for web apps) and (2) if your app communicates with any app-specific back end, the transfer of auth tokens between the app and back end is an additional temptation that is prone to have even more security issues. I do agree - if you have an app that is 100% client-side, and you're either using an official SDK or know what you're doing, implicit grants can be done securely (just as secure as any other bearer or session token, as you mention). The problem is that many app developers choose the implicit flow initially (because it's easier to implement), but then end up using it in ways that would be much better suited to the authorization grant flow.