News for hackers. Stuff that matters.

A comment on OAuth 2.0 Authentication Vulnerabilities.

Re:OAuth 2.0 Authentication Vulnerabilities by vwpolo3 on Saturday March 27, 2021 @12:54PM (#26603632)
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-1...

Generally you probably do not need 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

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by iecheruo on Saturday March 27, 2021 @02:01PM (#26604083)
From the article:

> OAuth authentication

> Although not originally intended for this purpose, OAuth has evolved into a means of authenticating users as well.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by ddek on Saturday March 27, 2021 @05:08PM (#26605645)
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.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Saturday March 27, 2021 @08:59PM (#26607120)
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.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by dwaite on Sunday March 28, 2021 @06:44PM (#26615487)
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.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by jjeaff on Saturday March 27, 2021 @08:08PM (#26606838)
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.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by UncleMeat on Saturday March 27, 2021 @02:54PM (#26604509)
In fact, there id say that the huge majority of oauth flows on the web are used for authentication at this point.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Saturday March 27, 2021 @09:07PM (#26607154)
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.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by UncleMeat on Saturday March 27, 2021 @09:50PM (#26607322)
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.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Saturday March 27, 2021 @10:19PM (#26607429)
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. :)
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by caseysoftware on Saturday March 27, 2021 @07:59PM (#26606793)
To be more precise, the flows are used to initiate authentication. They do not actually perform it.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by JoBrad on Saturday March 27, 2021 @08:26PM (#26606948)
Counterpoint: although SSN was not intended as a means of identification, it evolved into being used that way.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by mwcampbell on Saturday March 27, 2021 @10:25PM (#26607445)
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?
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by TriNetra on Sunday March 28, 2021 @02:14AM (#26608390)
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-t...

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Sunday March 28, 2021 @01:16AM (#26608167)
OAuth is overkill for what you're working on. You generally won't go wrong with the rule of thumb that you do the least amount of cryptography your design requires you to. You should be dragged kicking and screaming into more of it. In this case, generating a long random token and using that to authorize requests has all the basic security benefits of an OAuth bearer token and almost none of the attack surface. Long random tokens are the most overrated technology in authentication.

A general rule of thumb w/r/t/ OAuth is that it starts to make sense when you are delegating authorization to other companies that share your users. Think "TweetLater".

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by cpach on Sunday March 28, 2021 @08:49AM (#26609904)
“Long random tokens are the most overrated technology in authentication.”

Just so I follow, did you mean underrated…?

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Sunday March 28, 2021 @01:01PM (#26611976)
Yeah, sorry!
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by laurent92 on Sunday March 28, 2021 @04:35AM (#26608830)
But then you need to implement token revocation, by the host, the user or the client, and find a cryptographically-secure way to generate the key.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by wolf550e on Sunday March 28, 2021 @05:13AM (#26608951)
To revoke the token, the server deletes it from the database. If you have the token, you can ask the server to delete it from the database. The cryptographically secure way to generate it is to read 32 bytes from getrandom(2) or from /dev/urandom.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by merb on Sunday March 28, 2021 @09:45AM (#26610350)
you basically told somebody to roll his own crypto. that is a stupid idea. using refresh tokens and access tokens in a standard way is way more secure than rolling your own, this stuff is already pretty hard. of course one could go with a simple cookie login, but when it comes to external apps, that's not always a good idea, especially not if you need to revoke specific applications.

so your general rule of thumb is pretty stupid.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by wglb on Sunday March 28, 2021 @11:56AM (#26611370)
In what way is getting 32 bytes from /dev/urandom rolling your own crypto?
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by hirsin on Saturday March 27, 2021 @10:43PM (#26607501)
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.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by dwaite on Sunday March 28, 2021 @06:50PM (#26615543)
If you have no other features ever planned around authentication or authorization, and no other planned client software, you can build what you want in directly.

OAuth provides an abstraction between the authentication, permission grant and user consent and getting a token representing authorization, and provides additional best practices for things like securing web and native app access, token revocation, token introspection, etc. You probably want to be in the business of improving your SaaS, not designing a secure access system.

That isn't to say you can't build something now with the idea that you will migrate away from that once you hit an inflection point in complexity due to new features.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by tptacek on Sunday March 28, 2021 @10:13PM (#26617026)
I don't think it's at all the case that OAuth builds baseline best practices regarding authentication into applications. OAuth makes --- in fact, essentially is --- a series of concessions to enable delegated authorization, which is a much harder problem than simple authentication or single-site authentication. When you use OAuth in simplistic scenarios, you're importing all the challenges (and, as this page, the RFC, and a zillion other sources show, vulnerabilities) that OAuth has to deal with to make delegation work... but for no reason.

I'd generally caution against using OAuth until you know you need it.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by throwbacktictac on Saturday March 27, 2021 @10:45PM (#26607505)
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.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by ec109685 on Sunday March 28, 2021 @01:08AM (#26608132)
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.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by TriNetra on Sunday March 28, 2021 @02:32AM (#26608460)
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-d...

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by mooreds on Saturday March 27, 2021 @03:18PM (#26604715)
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).

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by dwaite on Sunday March 28, 2021 @07:04PM (#26615665)
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.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by oauea on Saturday March 27, 2021 @02:29PM (#26604307)
Nice, that page and your post is basically an ad. You don't need a proven open standard, you need our custom protocol instead!
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by pmh on Saturday March 27, 2021 @02:43PM (#26604427)
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
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by vwpolo3 on Saturday March 27, 2021 @04:33PM (#26605403)
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! :)
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by k__ on Saturday March 27, 2021 @01:03PM (#26603679)
Interesting, I always thought it was the other way around.

It would authenticate who you are, but you have authorize the people yourself later.

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by babelfish on Saturday March 27, 2021 @02:36PM (#26604361)
OpenID Connect is built on top of OAuth2 and is the recommended solution for authentication.
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by Osiris on Saturday March 27, 2021 @03:29PM (#26604842)
Your first link calls the specification "Open Authentication" which seems to contradict your statement that it's called "Open Authorization".
[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by vwpolo3 on Saturday March 27, 2021 @04:36PM (#26605426)
That looks like a mistake in the doc:

- https://oauth.net/articles/authentication/

- https://tools.ietf.org/html/rfc6749 - The OAuth 2.0 Authorization Framework

[ Parent | on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities by based2 on Saturday March 27, 2021 @01:32PM (#26603867)
-> OAuthz (vs authn)
[ Parent | on HN ]