4 ms·

Unfortunately, I've come across these kinds of issues first-hand in a number of existing projects. It usually comes down to the fact that a surprising number of

Unfortunately, I've come across these kinds of issues first-hand in a number of existing projects. It usually comes down to the fact that a surprising number of back end implementations trust data from the client without verification. Who's to blame? Well, the app / back end developers obviously, but I think it goes beyond that. As we all know, client-side frameworks are all the rage these days (receiving more attention than back end technologies, it seems), and with the popularity of BaaS providers (Firebase, Parse Server, etc), front end developers often feel over-confident in handling these things without really understanding what's going on underneath (and the security implications) because hey, "using a BaaS means I don't have to worry about that kind of stuff." 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?). Finally, some OAuth providers (ahem, Instagram) issue access tokens which should be opaque to the client, but obviously contain user data (e.g., user IDs) that tempt developers to take shortcuts. In one case, I saw an app that only looks at the access token itself (never using it to verify anything), parses it for a user ID (undocumented of course, but "it seems to work"), and simply exchanges that ID for a session token! A forged response allows anyone to impersonate any other user - simply with the Instagram ID of the target user. The horror... So yes, it does come down to developer incompetence, but my point is, the popular OAuth providers certainly aren't helping the situation by encouraging (or at least not discouraging) implicit OAuth grants, along with issuing not-so-opaque tokens that encourage bad developer behavior.

kemitche 10y ago
> 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.

kemitche 10y ago

> 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.