4 ms·

Just say no to the implicit grant. OAuth 2.1 removes most of the foot guns in OAuth: https://oauth.net/2.1/ https://oauth.net/2.1/

by tyho 3y ago

mooreds 3y ago
Hear hear! I've been following OAuth 2.1 for a couple of years. Can't wait for it to get released. If you want to check out the IETF draft, here is the current version: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm... Reading the "Differences from OAuth 2.0" section is helpful for understanding what changes are coming: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-differences-from-oauth-20 https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm... You can also give your feedback on this or any other draft on the IETF OAuth mailing list: https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth I've been lurking there for a long time and learned a lot; you can view the archives here: https://mailarchive.ietf.org/arch/browse/oauth/ https://mailarchive.ietf.org/arch/browse/oauth/
taeric 3y ago
Aren't the exploits here in not checking that the access token calling you was for you? That is, it wasn't the implicit grant, it was not checking the audience/signature of the token? What makes this an implicit grant problems?
- dwaite 3y ago
  Presumably, a confidential client identifies itself to the AS to exchange a code for an access token, so you know at that point that the access token was meant for that particular client. That said, Facebook Connect is an under-documented vendor extension to OAuth, and only is supported for use via the official SDKs. They do now have a bit more alignment with OpenID Connect and PKCE as an option, but I imagine most existing parties do not use it. https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow https://developers.facebook.com/docs/facebook-login/guides/a...
  - taeric 3y ago
    But wasn't this a case of the frontend client using harvested tokens from somewhere else?
peter_l_downs 3y ago
Hard to believe this isn't common practice at this point. Way back when I was just getting started in my career I implemented an OAuth 2.0 server and it was already accepted that auth code grants were the only reasonable way to do things. Here's what I wrote in the docs for that project: The decisions that are most important to the security of your application are: - The authorization endpoint will only return authorization codes, which can later be exchanged for access tokens. - Password credentials grants, implicit grants, client credentials grants, and all extension grants are not supported. - Public clients are not supported. - Every client is required to register its redirect_uri. - All authorization, token, and API requests are required to use TLS encryption in order to prevent credentials from being leaked to a third-party. In addition, the registered redirect_uri must also be secured with TLS. - Clients are required to CSRF-protect their redirection endpoints. https://djoauth2.readthedocs.io/en/latest/overview.html#what-is-implemented https://djoauth2.readthedocs.io/en/latest/overview.html#what...
- ranting-moth 3y ago
  As for the "hard to believe", consider this: The guys who implemented this in the flawed way are probably at least twice as productive as the guys who'd thoroughly read the task and implement it correctly.
zemnmez 3y ago
OIDC+OAuth is what most people actually want when they think of OAuth imo. The main issue here is that OAuth was not designed as an authentication protocol.

Just say no to the implicit grant. OAuth 2.1 removes most of the foot guns in OAuth: https://oauth.net/2.1/ https://oauth.net/2.1/

by tyho 3y ago

Just say no to the implicit grant. OAuth 2.1 removes most of the foot guns in OAuth: https://oauth.net/2.1/ https://oauth.net/2.1/

mooreds 3y ago

Hear hear! I've been following OAuth 2.1 for a couple of years. Can't wait for it to get released. If you want to check out the IETF draft, here is the current version: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm... Reading the "Differences from OAuth 2.0" section is helpful for understanding what changes are coming: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-differences-from-oauth-20 https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.htm... You can also give your feedback on this or any other draft on the IETF OAuth mailing list: https://www.ietf.org/mailman/listinfo/oauth https://www.ietf.org/mailman/listinfo/oauth I've been lurking there for a long time and learned a lot; you can view the archives here: https://mailarchive.ietf.org/arch/browse/oauth/ https://mailarchive.ietf.org/arch/browse/oauth/

taeric 3y ago

Aren't the exploits here in not checking that the access token calling you was for you? That is, it wasn't the implicit grant, it was not checking the audience/signature of the token? What makes this an implicit grant problems?

dwaite 3y ago
Presumably, a confidential client identifies itself to the AS to exchange a code for an access token, so you know at that point that the access token was meant for that particular client. That said, Facebook Connect is an under-documented vendor extension to OAuth, and only is supported for use via the official SDKs. They do now have a bit more alignment with OpenID Connect and PKCE as an option, but I imagine most existing parties do not use it. https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow https://developers.facebook.com/docs/facebook-login/guides/a...
- taeric 3y ago
  But wasn't this a case of the frontend client using harvested tokens from somewhere else?

peter_l_downs 3y ago

Hard to believe this isn't common practice at this point. Way back when I was just getting started in my career I implemented an OAuth 2.0 server and it was already accepted that auth code grants were the only reasonable way to do things. Here's what I wrote in the docs for that project: The decisions that are most important to the security of your application are: - The authorization endpoint will only return authorization codes, which can later be exchanged for access tokens. - Password credentials grants, implicit grants, client credentials grants, and all extension grants are not supported. - Public clients are not supported. - Every client is required to register its redirect_uri. - All authorization, token, and API requests are required to use TLS encryption in order to prevent credentials from being leaked to a third-party. In addition, the registered redirect_uri must also be secured with TLS. - Clients are required to CSRF-protect their redirection endpoints. https://djoauth2.readthedocs.io/en/latest/overview.html#what-is-implemented https://djoauth2.readthedocs.io/en/latest/overview.html#what...

ranting-moth 3y ago
As for the "hard to believe", consider this: The guys who implemented this in the flawed way are probably at least twice as productive as the guys who'd thoroughly read the task and implement it correctly.

zemnmez 3y ago

OIDC+OAuth is what most people actually want when they think of OAuth imo. The main issue here is that OAuth was not designed as an authentication protocol.