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).
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.
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.
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.
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.
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.
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. :)
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?
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.
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".
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.
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 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.
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.
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.
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.
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.
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).
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.
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
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! :)
If you are going to use keycloak it's worth making sure their mental model matches your own. Specifically we had issues with our model of multi-tennacy, each in their own realm vs. the keycloak idea of multiple tennants in a single realm. It caused some large performance and management issues.
Ory is really interesting but not, IMO, quite there yet. There are a bunch of Kratos features that aren't there but, once they are, I think it's a really compelling option.
We used ORY fosite to write our auth service, and I have so far really enjoyed working with the lib. Feels like they aren't as focused on external users of the fosite lib though so much as their hydra solution which consumes it. The overall ORY ecosystem seems nice though, though I have not delved into it in detail past fosite.
If you're looking for next generation of identity solutions? https://magic.link is what everyone would need, provides decentralised identity, fair pricing and no vendor lock-in.
I hate this magic link flow. Its a major pain in my ass when I already have a password manager that knows how to login. Now I have to leave my browser and go to my e-mail client that will open a new tab even though I already have one open.
Thanks for the link. I'm rolling my own for a reason. I'm working on not only an Oauth2 implementation, but also a specification for using Oauth2 for filesystem operations (btw if you're aware of such a thing existing already, I'd love to hear about it). So I need to be intimately familiar with Oauth2. I wasn't originally planning to use it, but ultimately it's close enough to what I need, and for better or worse users are familiar with the flows.
> btw if you're aware of such a thing existing already, I'd love to hear about it
Since OAuth is pretty coarse-grained, you tend to have:
- A client has a policy configured for the file sharing service or file collection, and does not use e.g. the scope parameter to request particular permissions
- A file collection lets scopes be assigned particular permissions, and a client requests access by requesting one or more scopes
Although I am not a fan of the level of complexity it adds, UMA (User Managed Access) makes a pretty strong attempt at solving these sorts of problems as well.
Then when the authorization screen is presented, the user could even modify the permissions granted on the fly.
Usually applications only need a single directory to store data, and it shouldn't matter to the app where that directory is in relation to the rest of the user's data. In that case you could do something like this:
scope="dir?:write"
Which tells the authorization server to present the user with a directory picker, so the user has control over where the data is stored. It doesn't make any sense to give write permissions to all your data for every single application.
After 5 minutes of poking around, I still don't understand how exactly UMA works in relation to Oauth2. I agree it seems to be pretty complex.
Ory | Open Source Software Engineer (Go, React) | FULLTIME | ONSITE in Munich Germany
We build stuff for an emerging cloud infrastructure. It's security, zero trust, hardcore bullet proof engineering. It's Golang, K8S, React, Hashicorp etc. - no more buzzwords!
We are looking for people with a broad set of technical skills who are ready to take on some of technology's challenges and work with others to create modern world class solutions. We like React, Go and Kubernetes (among other things) and love learning how to push the boundaries with those technologies!
Drop us a short introductory email to jobs@ory.sh. We believe that great engineering deserves to be paid accordingly.
The problem is that online news sources are (almost) all the same - low budget, second tier silos of mostly trainee journalists. They have an emphasis on clicks and outrage and constant updates to keep you engaged and are a secondary (or tertiary) driver of revenue. The only exception I know of are The New York Times and maybe The Intercept.
My tip is to read a (or more) actual (read: printed) newspapers:
- they are printed daily or weekly (e.g. The Economist), keeping you out of the "Breaking News" loop every 60 minutes;
- they have more weight within the news organization because they are the primary driver of revenue;
- are therefore written by actual professional journalists in a proper journalistic process.
I recommend just picking up any news paper and comparing that to the online presence of that news paper, you will notice the tremendous difference.
In my opinion, a lot of the "media mistrust" comes from the constant barrage of so-called "news" articles with the primary goal of being shared on social media and bubbling up in Google News. Just check how many news articles are 1:1 copies of AP or any other news conglomerate.
https://newshound.co/editions/en-us/ is pretty good for seeing how many news articles published by different outlets are actually written by AP/Reuters/etc. and only modified slightly. I think the site was originally intended to allow users to choose the article from their preferred outlet, but I rarely find myself interested in reading any of the grouped articles.
I like the same thing about https://techmeme.com/ if I click the arrow next to a story, it shows me everyone covering it, but they use editorial discretion to chose the "best" coverage, whether that be the first copy, or the first good copy.
There’s a reason it seems online sources are the same. Step outside the conglomerates, and choose independent news.
See the following list for a “growing number of independent news sources available to anyone with internet access. The following are only a sampling of those alternatives. Most state that they are “non-partisan, independent and non-profit.” Some are more transparent than others; a couple even outline a code of journalistic ethics their company follows.”
The Intercept started out strong, but has also devolved into reactionary clickbait-y crap as of late (also hosts pieces written by unrepentant race-baiters like Shaun King). Really sad as I used to like them.
It seems those with hard paywalls that don't have to rely on clickbait-y headlines are able to have a bit more integrity (who would have known?!). Foreign Affairs is generally pretty good for actual analysis on world events (it's politics, yes, but they are good at what they do).
The blog posts and discussion was long ago (the video is 6 years old). Since then, that particular author acknowledged that (iirc) OpenID Connect solves many of the things he criticized. I have to look up the source, it’s been a while.
However, OIDC and OAuth2 are complex protocols which is also why we encourage most greenfield and small projects to avoid it unless explicitly required.
It’s also important to note that that particular person voiced criticism, but most of the biggest names in tech (GCP, AWS, ...) heavily rely on those protocols (+ extensions). His proposed alternative protocol Oz never got to real world adoption (to my knowledge) and has recently been archived. The prediction that we would see major OAuth2 security wholes within 3 years (so 2015j never came true. It doesn’t mean that he was wrong, but that there are opinions that contradict him, and that those opinions and voices have established themselves in the industry.
The BCP recommends either sending back client_id and iss (but that draft[1] is long expired, and nobody seems to support that implementation), or asking the client to provider a separate exact-match return URI for each AS. The second solution is what I'm doing when implementing multi-AS/IdP OAuth clients, but this requires the clients to be aware of this vulnerability, and that's a rather tall requirement.
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