8 ms·

OAuth 2.0 Authentication Vulnerabilities

174 points by lobo_tuerto 6y ago

vwpolo3 6y ago
The first vulnerability is in the title, OAuth is an Authorization framework (Open Authorization) and is explicitly NOT for authentication. It’s also a delegation protocol (I give you something to do on my behalf). If you want a list of things that can go wrong, look here: https://tools.ietf.org/id/draft-ietf-oauth-security-topics-10.html https://tools.ietf.org/id/draft-ietf-oauth-security-topics-1... Generally you probably do not need OAuth2: https://www.ory.sh/hydra/docs/concepts/before-oauth2/ https://www.ory.sh/hydra/docs/concepts/before-oauth2/ But if you do don’t roll your own but use proven open source like https://github.com/ory/hydra https://github.com/ory/hydra
- k__ 6y ago
  Interesting, I always thought it was the other way around. It would authenticate who you are, but you have authorize the people yourself later.
  - babelfish 6y ago
    OpenID Connect is built on top of OAuth2 and is the recommended solution for authentication.
- based2 6y ago
  -> OAuthz (vs authn)
- iecheruo 6y ago
  From the article: > OAuth authentication > Although not originally intended for this purpose, OAuth has evolved into a means of authenticating users as well.
  - UncleMeat 6y ago
    In fact, there id say that the huge majority of oauth flows on the web are used for authentication at this point.
    - caseysoftware 6y ago
      To be more precise, the flows are used to initiate authentication. They do not actually perform it.
    - tptacek 6y ago
      If you mean, like, logging into things with Google, sure, but isn't that technically OIDC? If you mean to say "most OAuth is used for OIDC, and is thus authentication", that's a different and less interesting claim. If instead you're saying that vanilla OAuth is primarily used for authentication, you're saying something more interesting (and problematic). You can use vanilla OAuth to log in, but you're adding a particularly subtle class of possible flaws in your design by doing so.
      - UncleMeat 6y ago
        I mean the former. The primary use case of oauth on the modern web is to support openid connect. So much so that I expect it'll be a "SSL vs TLS" thing in the future where we actually use "oauth" to refer to the entire openid connect flow.
        tptacek 6y ago
        Sure, OK. But this article really thinking about OAuth authentication in terms of OAuth itself, not OIDC. The dominant use of TCP on the Internet is (I hope?) to fetch URLs, but HTTP is not TCP. :)
  - ddek 6y ago
    The OAuth 2.0 RFC specifies the 'password' grant type, where the user provides the username and password directly. I'd contest the claim that OAuth was not intended for authentication, because there are no authz uses for the password grant.
    - tptacek 6y ago
      It famously wasn't intended for authentication, which is why OIDC was developed on top of it. Trying to run a delegated authorization protocol as an authentication protocol caused vulnerabilities. There are obvious authz uses for the password grant: you use it when you want to delegate access to a client running on your desktop, which is in your custody, and there's no point in running a multi-legged authorization protocol because you can just log the client in yourself. Your first thought about that might be "that's authentication", but it's not: you don't have to give all-or-nothing access (in theory) to such a client.
    - dwaite 6y ago
      OAuth 2.0 password grant can be (mis)used for authentication the same way that LDAP Bind is used for authentication. That doesn't make either of them an authentication protocol.
  - jjeaff 6y ago
    I've been seeing more and more apps and websites have me login with my xyz app login info. Then, ask if it's ok to grant access to xyz app so it can access xyz app information. Makes sense only if you are a developer. You are granting the frontend access to the backend via oauth. Completely confusing for everyone else and was pretty confusing for me at first as well.
  - JoBrad 6y ago
    Counterpoint: although SSN was not intended as a means of identification, it evolved into being used that way.
- oauea 6y ago
  Nice, that page and your post is basically an ad. You don't need a proven open standard, you need our custom protocol instead!
  - pmh 6y ago
    From a quick glance, it doesn't look like a protocol per se, but a user management system akin to Keycloak. Those solve a slightly different set of problems than OIDC or OAuth
  - vwpolo3 6y ago
    It explains why OAuth2 is hard to use and does not solve login, registration, sessions, profile management, mfa, and proposes another solution. It’s all open source! :)
- mooreds 6y ago
  It is designed for authorization but as sibling comments have said, it is very often used for authentication. Even though good old RFC 6749 says nothing about the details of authentication and leaves the nitty gritty of that to the Authorization server. But almost every OAuth server I'm aware of has some kind of authentication functionality. 100% agree that you should not roll your own. There are lots and lots of options out there with different strengths and weaknesses. Determine what you need and then find the right solution (which may be hydra or something else).
  - dwaite 6y ago
    RFC 6749 does not contain any to verify tokens are usable for authentication, and is insecure (and has been exploited) when used for authentication on its own. You have extensions like Facebook Connect or OpenID Connect which add on the additional technology and client steps to allow it to be used securely for authentication. The title is wrong because those involved in the standardization of OAuth 2.0 have yelled from the very beginning not to use it for authentication, but instead use something that builds authentication on top of it.
- Osiris 6y ago
  Your first link calls the specification "Open Authentication" which seems to contradict your statement that it's called "Open Authorization".
  - vwpolo3 6y ago
    That looks like a mistake in the doc: - https://oauth.net/articles/authentication/ https://oauth.net/articles/authentication/ - https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749 - The OAuth 2.0 Authorization Framework
- mwcampbell 6y ago
  I'm currently trying to decide if OAuth is overkill for something I'm working on: a first-party browser extension for a SaaS. The extension needs to authenticate the user with the SaaS on installation, then make API calls to the SaaS on the user's behalf. In theory, OAuth is a good idea because it's a standard, as opposed to some ad-hoc system that I cook up myself. But if I try to use an off-the-shelf OAuth provider implementation in the SaaS, it's obvious that I'm not using it for its intended purpose, because when a user goes through the OAuth authorization flow, they get a screen asking whether they authorize the app to access the service. But in the user's mind, the app (the browser extension) is part of the service. So, does that just mean I need to tweak the OAuth provider? Or is this a hint that I should go with a simpler solution?
  - hirsin 6y ago
    So called "first party apps", those that are first party to the IDP, can often be considered as pre-consented. So the consent can be skipped - it's why you don't need to consent to use Excel or Gmail.
  - throwbacktictac 6y ago
    I think it make sense to have a oAuth service for it. Like you said, it standard and straight forward. If you will have third party consume your users API you won't have to put too much effort into coming up with a different scheme. google and TDAmeritrade authenticate their 1st party services with oAuth and it logically makes sense to me.
  - TriNetra 6y ago
    You can use HMAC [0]. Create a UI to collect username/password and make an API call to login endpoint, which should return sessionId/secret. going forward sign API requests using the HMAC protocol without ever revealing the secret on the wire again. 0: https://aspsecuritykit.net/guides/implementing-hmac-scheme-to-protect-api-requests/ https://aspsecuritykit.net/guides/implementing-hmac-scheme-t...
  - ec109685 6y ago
    Nest does this. When you auth with Google, it asks for consent, even though they are owned by same company. Agree below though on preconsent.
- TriNetra 6y ago
  In reality, most of the applications are using it for authentication: to identify who you are using your GitHub, FaceBook or Google account. Authorization is the process of determining whether the identity can perform the specified action on the specified data [0]; such social logins provide close to no real options to users to specify this aspect. 0: https://aspsecuritykit.net/guides/designing-activity-based-data-aware-authorization/ https://aspsecuritykit.net/guides/designing-activity-based-d...
progre 6y ago
Regarding the access token... > the server does not have any secrets or passwords to compare with the submitted data, which means that it is implicitly trusted The access token should be signed right? So it's not implicitly trusted. The server must of course validate the access token using the public key indicated in the token, and of course only accept tokens from trusted providers. Maybe I'm not reading this right.
- UnlockedSecrets 6y ago
  It can be authenticated as coming from a trusted party but cannot be authenticated against a user password because the system has no way of knowing any secrets provided by the user.
  - progre 6y ago
    Well, that's kind of the point right? Keeping user secrets out of the trusting system.
- mooreds 6y ago
  That whole section is about the implicit grant anyway, which should be avoided. As far as validating tokens, access tokens are 'opaque' in OAuth2; the token format is not defined by the spec. (In OIDC, they are JSON web tokens.) For OAuth, you can make a call to the introspect endpoint and the Authorization Server will tell you if it is a valid token. In practice, OAuth servers often issue JWTs, and there's a draft spec out to make them interoperable: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-11 https://tools.ietf.org/html/draft-ietf-oauth-access-token-jw... If you are a resource server consuming an access token and you know the token is a JWT, you should check the following at a minimum: * the token is signed according to the algo and the key that you expect * the token is not expired (the `exp` claim) and is currently valid (the `nbf` claim, if present) * the token is issued by who you expect (the `iss` claim) (which is the point you are making about 'trusted providers') * the token is issued for you (the `aud` claim) Most libraries I have interacted with check the first two, but not the last two.
  - 6y ago
mooreds 6y ago
Great post. I work in the space and am coming up to speed on some of the security issues. Comments: * this is a great read about security and OAuth: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... written by experienced folks. * don't use the implicit grant, please. Use the authorization code grant with PKCE. Here's an example (from a doc I helped write, talking about how bad the implicit grant is: https://fusionauth.io/learn/expert-advice/oauth/modern-guide-to-oauth/#implicit-grant-in-oauth-20 https://fusionauth.io/learn/expert-advice/oauth/modern-guide... * State can be used for CSRF protection but I've also seen it used to convey, well, state that needs to be carried over. That's legitimate, but make sure you append a random value as suggested. * The well known endpoints will only be present if the OAuth server supports RFC 8414: https://tools.ietf.org/html/rfc8414 https://tools.ietf.org/html/rfc8414 but you can always check the documentation. Most OAuth servers have plenty of public documentation to make their usage easier. * Re "Flawed redirect_uri validation", the OAuth 2.1 spec has tightened this up some and wants exact URI matching. We have some customers who want wildcard matching, but the redirect_uri check is a fundamental part of the OAuth security architecture, so we've resisted that request. * "However, by stealing an OAuth code or token, the attacker can gain access to the user's account in their own browser." is a good reminder that you should keep your token lifetimes short. We recommend minutes; use a refresh token to renew the token. All in all, thought provoking article. There's a reason why more and more teams are outsourcing auth; there's a lot of flexibility in the specs and it's easy to make mistakes. Even when you do it right the first time, there's ongoing maintenance. You should run a bug bounty program and/or regularly pentest your system.
- zemnmez 6y ago
  > don't use the implicit grant, please. Use the authorization code grant with PKCE. Here's an example (from a doc I helped write, talking about how bad the implicit grant is: https://fusionauth.io/learn/expert-advice/oauth/modern-guide https://fusionauth.io/learn/expert-advice/oauth/modern-guide... This is a bit of a strange security model. The implicit grant vulnerability mentioned is essentially a supply chain attack where an untrusted library is loaded. True, it can compromise the implicit grant token, but, in a mode where the implicit grant token is hidden, it's still talking as the website, and can do ~most~ anything, more or less that the token can do by making a request with the cookie, or whatever.
waynesonfire 6y ago
You had one job...
LordGrey 6y ago
OAuth 2.1 addresses some of the deficiencies in OAuth 2.0. In summary: * PKCE is required for all OAuth clients using the authorization code flow * Redirect URIs must be compared using exact string matching * The Implicit grant (response_type=token) is omitted from this specification * The Resource Owner Password Credentials grant is omitted from this specification * Bearer token usage omits the use of bearer tokens in the query string of URIs * Refresh tokens for public clients must either be sender-constrained or one-time use See https://oauth.net/2.1/ https://oauth.net/2.1/

174 points by lobo_tuerto 6y ago

The first vulnerability is in the title, OAuth is an Authorization framework (Open Authorization) and is explicitly NOT for authentication. It’s also a delegation protocol (I give you something to do on my behalf). If you want a list of things that can go wrong, look here: https://tools.ietf.org/id/draft-ietf-oauth-security-topics-10.html https://tools.ietf.org/id/draft-ietf-oauth-security-topics-1... Generally you probably do not need OAuth2: https://www.ory.sh/hydra/docs/concepts/before-oauth2/ https://www.ory.sh/hydra/docs/concepts/before-oauth2/ But if you do don’t roll your own but use proven open source like https://github.com/ory/hydra https://github.com/ory/hydra

k__ 6y ago
Interesting, I always thought it was the other way around. It would authenticate who you are, but you have authorize the people yourself later.
- babelfish 6y ago
  OpenID Connect is built on top of OAuth2 and is the recommended solution for authentication.
based2 6y ago
-> OAuthz (vs authn)
iecheruo 6y ago
From the article: > OAuth authentication > Although not originally intended for this purpose, OAuth has evolved into a means of authenticating users as well.
- UncleMeat 6y ago
  In fact, there id say that the huge majority of oauth flows on the web are used for authentication at this point.
  - caseysoftware 6y ago
    To be more precise, the flows are used to initiate authentication. They do not actually perform it.
  - tptacek 6y ago
    If you mean, like, logging into things with Google, sure, but isn't that technically OIDC? If you mean to say "most OAuth is used for OIDC, and is thus authentication", that's a different and less interesting claim. If instead you're saying that vanilla OAuth is primarily used for authentication, you're saying something more interesting (and problematic). You can use vanilla OAuth to log in, but you're adding a particularly subtle class of possible flaws in your design by doing so.
    - UncleMeat 6y ago
      I mean the former. The primary use case of oauth on the modern web is to support openid connect. So much so that I expect it'll be a "SSL vs TLS" thing in the future where we actually use "oauth" to refer to the entire openid connect flow.
      - tptacek 6y ago
        Sure, OK. But this article really thinking about OAuth authentication in terms of OAuth itself, not OIDC. The dominant use of TCP on the Internet is (I hope?) to fetch URLs, but HTTP is not TCP. :)
- ddek 6y ago
  The OAuth 2.0 RFC specifies the 'password' grant type, where the user provides the username and password directly. I'd contest the claim that OAuth was not intended for authentication, because there are no authz uses for the password grant.
  - tptacek 6y ago
    It famously wasn't intended for authentication, which is why OIDC was developed on top of it. Trying to run a delegated authorization protocol as an authentication protocol caused vulnerabilities. There are obvious authz uses for the password grant: you use it when you want to delegate access to a client running on your desktop, which is in your custody, and there's no point in running a multi-legged authorization protocol because you can just log the client in yourself. Your first thought about that might be "that's authentication", but it's not: you don't have to give all-or-nothing access (in theory) to such a client.
  - dwaite 6y ago
    OAuth 2.0 password grant can be (mis)used for authentication the same way that LDAP Bind is used for authentication. That doesn't make either of them an authentication protocol.
- jjeaff 6y ago
  I've been seeing more and more apps and websites have me login with my xyz app login info. Then, ask if it's ok to grant access to xyz app so it can access xyz app information. Makes sense only if you are a developer. You are granting the frontend access to the backend via oauth. Completely confusing for everyone else and was pretty confusing for me at first as well.
- JoBrad 6y ago
  Counterpoint: although SSN was not intended as a means of identification, it evolved into being used that way.
oauea 6y ago
Nice, that page and your post is basically an ad. You don't need a proven open standard, you need our custom protocol instead!
- pmh 6y ago
  From a quick glance, it doesn't look like a protocol per se, but a user management system akin to Keycloak. Those solve a slightly different set of problems than OIDC or OAuth
- vwpolo3 6y ago
  It explains why OAuth2 is hard to use and does not solve login, registration, sessions, profile management, mfa, and proposes another solution. It’s all open source! :)
mooreds 6y ago
It is designed for authorization but as sibling comments have said, it is very often used for authentication. Even though good old RFC 6749 says nothing about the details of authentication and leaves the nitty gritty of that to the Authorization server. But almost every OAuth server I'm aware of has some kind of authentication functionality. 100% agree that you should not roll your own. There are lots and lots of options out there with different strengths and weaknesses. Determine what you need and then find the right solution (which may be hydra or something else).
- dwaite 6y ago
  RFC 6749 does not contain any to verify tokens are usable for authentication, and is insecure (and has been exploited) when used for authentication on its own. You have extensions like Facebook Connect or OpenID Connect which add on the additional technology and client steps to allow it to be used securely for authentication. The title is wrong because those involved in the standardization of OAuth 2.0 have yelled from the very beginning not to use it for authentication, but instead use something that builds authentication on top of it.
Osiris 6y ago
Your first link calls the specification "Open Authentication" which seems to contradict your statement that it's called "Open Authorization".
- vwpolo3 6y ago
  That looks like a mistake in the doc: - https://oauth.net/articles/authentication/ https://oauth.net/articles/authentication/ - https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749 - The OAuth 2.0 Authorization Framework
mwcampbell 6y ago
I'm currently trying to decide if OAuth is overkill for something I'm working on: a first-party browser extension for a SaaS. The extension needs to authenticate the user with the SaaS on installation, then make API calls to the SaaS on the user's behalf. In theory, OAuth is a good idea because it's a standard, as opposed to some ad-hoc system that I cook up myself. But if I try to use an off-the-shelf OAuth provider implementation in the SaaS, it's obvious that I'm not using it for its intended purpose, because when a user goes through the OAuth authorization flow, they get a screen asking whether they authorize the app to access the service. But in the user's mind, the app (the browser extension) is part of the service. So, does that just mean I need to tweak the OAuth provider? Or is this a hint that I should go with a simpler solution?
- hirsin 6y ago
  So called "first party apps", those that are first party to the IDP, can often be considered as pre-consented. So the consent can be skipped - it's why you don't need to consent to use Excel or Gmail.
- throwbacktictac 6y ago
  I think it make sense to have a oAuth service for it. Like you said, it standard and straight forward. If you will have third party consume your users API you won't have to put too much effort into coming up with a different scheme. google and TDAmeritrade authenticate their 1st party services with oAuth and it logically makes sense to me.
- TriNetra 6y ago
  You can use HMAC [0]. Create a UI to collect username/password and make an API call to login endpoint, which should return sessionId/secret. going forward sign API requests using the HMAC protocol without ever revealing the secret on the wire again. 0: https://aspsecuritykit.net/guides/implementing-hmac-scheme-to-protect-api-requests/ https://aspsecuritykit.net/guides/implementing-hmac-scheme-t...
- ec109685 6y ago
  Nest does this. When you auth with Google, it asks for consent, even though they are owned by same company. Agree below though on preconsent.
TriNetra 6y ago
In reality, most of the applications are using it for authentication: to identify who you are using your GitHub, FaceBook or Google account. Authorization is the process of determining whether the identity can perform the specified action on the specified data [0]; such social logins provide close to no real options to users to specify this aspect. 0: https://aspsecuritykit.net/guides/designing-activity-based-data-aware-authorization/ https://aspsecuritykit.net/guides/designing-activity-based-d...

progre 6y ago

Regarding the access token... > the server does not have any secrets or passwords to compare with the submitted data, which means that it is implicitly trusted The access token should be signed right? So it's not implicitly trusted. The server must of course validate the access token using the public key indicated in the token, and of course only accept tokens from trusted providers. Maybe I'm not reading this right.

UnlockedSecrets 6y ago
It can be authenticated as coming from a trusted party but cannot be authenticated against a user password because the system has no way of knowing any secrets provided by the user.
- progre 6y ago
  Well, that's kind of the point right? Keeping user secrets out of the trusting system.
mooreds 6y ago
That whole section is about the implicit grant anyway, which should be avoided. As far as validating tokens, access tokens are 'opaque' in OAuth2; the token format is not defined by the spec. (In OIDC, they are JSON web tokens.) For OAuth, you can make a call to the introspect endpoint and the Authorization Server will tell you if it is a valid token. In practice, OAuth servers often issue JWTs, and there's a draft spec out to make them interoperable: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-11 https://tools.ietf.org/html/draft-ietf-oauth-access-token-jw... If you are a resource server consuming an access token and you know the token is a JWT, you should check the following at a minimum: * the token is signed according to the algo and the key that you expect * the token is not expired (the `exp` claim) and is currently valid (the `nbf` claim, if present) * the token is issued by who you expect (the `iss` claim) (which is the point you are making about 'trusted providers') * the token is issued for you (the `aud` claim) Most libraries I have interacted with check the first two, but not the last two.
- 6y ago

mooreds 6y ago

Great post. I work in the space and am coming up to speed on some of the security issues. Comments: * this is a great read about security and OAuth: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16 https://tools.ietf.org/html/draft-ietf-oauth-security-topics... written by experienced folks. * don't use the implicit grant, please. Use the authorization code grant with PKCE. Here's an example (from a doc I helped write, talking about how bad the implicit grant is: https://fusionauth.io/learn/expert-advice/oauth/modern-guide-to-oauth/#implicit-grant-in-oauth-20 https://fusionauth.io/learn/expert-advice/oauth/modern-guide... * State can be used for CSRF protection but I've also seen it used to convey, well, state that needs to be carried over. That's legitimate, but make sure you append a random value as suggested. * The well known endpoints will only be present if the OAuth server supports RFC 8414: https://tools.ietf.org/html/rfc8414 https://tools.ietf.org/html/rfc8414 but you can always check the documentation. Most OAuth servers have plenty of public documentation to make their usage easier. * Re "Flawed redirect_uri validation", the OAuth 2.1 spec has tightened this up some and wants exact URI matching. We have some customers who want wildcard matching, but the redirect_uri check is a fundamental part of the OAuth security architecture, so we've resisted that request. * "However, by stealing an OAuth code or token, the attacker can gain access to the user's account in their own browser." is a good reminder that you should keep your token lifetimes short. We recommend minutes; use a refresh token to renew the token. All in all, thought provoking article. There's a reason why more and more teams are outsourcing auth; there's a lot of flexibility in the specs and it's easy to make mistakes. Even when you do it right the first time, there's ongoing maintenance. You should run a bug bounty program and/or regularly pentest your system.

zemnmez 6y ago
> don't use the implicit grant, please. Use the authorization code grant with PKCE. Here's an example (from a doc I helped write, talking about how bad the implicit grant is: https://fusionauth.io/learn/expert-advice/oauth/modern-guide https://fusionauth.io/learn/expert-advice/oauth/modern-guide... This is a bit of a strange security model. The implicit grant vulnerability mentioned is essentially a supply chain attack where an untrusted library is loaded. True, it can compromise the implicit grant token, but, in a mode where the implicit grant token is hidden, it's still talking as the website, and can do ~most~ anything, more or less that the token can do by making a request with the cookie, or whatever.

waynesonfire 6y ago

You had one job...

LordGrey 6y ago

OAuth 2.1 addresses some of the deficiencies in OAuth 2.0. In summary: * PKCE is required for all OAuth clients using the authorization code flow * Redirect URIs must be compared using exact string matching * The Implicit grant (response_type=token) is omitted from this specification * The Resource Owner Password Credentials grant is omitted from this specification * Bearer token usage omits the use of bearer tokens in the query string of URIs * Refresh tokens for public clients must either be sender-constrained or one-time use See https://oauth.net/2.1/ https://oauth.net/2.1/