Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OAuth 2.0 Security Best Current Practice

tools.ietf.org

Post reply on HN
Print view View original

91–98 of 98 posts

Re: OAuth 2.0 Security Best Current Practice

#91

Post by anentropic »

abhishektwr wrote: post #68

I need to read this draft RFC a few times before I can grasp it completely. There is an existing RFC drafted in 2013 with a focus on OAuth 2.0 threat model and security considerations [1], and it looks like this new RFC is making more specific recommendations on top of it. May be read them together. To be honest, I was wishing for OAuth 2.5 if not OAuth 3.0 to consolidate already fragmented OAuth 2.0 spec and landsca…

You need an API gateway, you don't want your clients tightly coupled to the individual services

Re: OAuth 2.0 Security Best Current Practice

#92

Post by mooreds »

1cvmask wrote: post #74
mooreds wrote: post #44

Earlier quoted context omitted.

> Whatever you do, don't write your own oauth server. I wish I could upvote this 10 times. There are open source solutions. There are closed source solutions. There are SaaS solutions. Pick a solution that meets your needs. Build the differentiating features of your app, not an OAuth server.

Any recommendations or favorites, and any to avoid?

Hiya,

I'm employed by a company which provides an OAuth implementation which I think is worth evaluating; you can look at other comments on this post or in my profile for more details. Happy to chat more over email, which is also in my profile, if that'd be helpful.

Since I don't know your use cases or needs, I would like to take a step back and think about what a developer might think about when evaluating this type of decision. Here are some things I'd consider:

* what does your organization currently use? If your org has experience with an identity solution, I'd evaluate that very seriously. It might not fit all your needs, especially if it is focused on IAM (identity and access management) as opposed to CIAM (customer identity and access management) but since your org uses it and presumably knows how to operate it, start there.

* cost of a solution. What does it cost to run the solution every month? What costs to set up the solution? Don't forget to estimate the time of staff to operate--even if I handed you a great solution for free, it would take an engineer's time to get it up and running, and that costs money.

* features and functionality. These could be what you might think of as features (does it support passwordless, what languages have client libraries, what standards like SAML, WS-Fed, OIDC, LDAP are supported) as well as non functional requirements like tenancy, performance and data center locality (sometimes governments have requirements about where user data can live).

I've built a number of software applications and I can tell you that I wish I'd started out with a separate identity provider more often. It makes it easier to create a single sign on experience, add more applications, and enable new functionality. Add that to the fact that identity is a necessary but not sufficient requirement that doesn't often differentiate or add much value to your application. If you're building a todo app, people expect to be able to login but will rarely rave about how smooth the login experience is :) . If you find a solution that works, you can often drop it in and accelerate delivery of the real value of your application, while giving you flexibility for the future.

Finally, here's a video from RailsConf about the dangers of rolling your own user identity management: https://railsconf.com/2020/video/seyed-m-nasehi-why-you-shou... . I don't know the speaker, but certainly some of the issues his hedgehogs (no, really) encountered seemed familiar.

Re: OAuth 2.0 Security Best Current Practice

#94

Post by jcranmer »

Sandhose wrote: post #90
jcranmer wrote: post #47

Earlier quoted context omitted.

When I was looking up the OAUTHBEARER draft, there's a (OPTIONAL) field in the error response to point to the openid-configuration for dynamic registration. At the time I was implementing things for Thunderbird, no one was using this yet, and I would be surprised if this has actually been implemented by any major provider in any sort of usable way for clients.

Did you end up implementing it in Thunderbird? We're looking to do that at my company and I'm currently implementing OAUTHBEARER in cyrus-sasl (which then could be used in cyrus-imapd & postfix)

I haven't implemented it myself, and as far as I'm aware, it hasn't been in the past few years. If it is going into cyrus-sasl, then I can probably put together containers for testing (which is on my work todo list anyways).

Re: OAuth 2.0 Security Best Current Practice

#95

Post by anderspitman »

dwaite wrote: post #66
anderspitman wrote: post #55

Earlier quoted context omitted.

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 use…

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

But why do they have to be coarse-grained? If you have a cloud storage provider, why not allow scopes to be set per path, like this:

scope="/dir1:read /dir2:write /dir3/file.txt:read"

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.

Re: OAuth 2.0 Security Best Current Practice

#96

Post by KajMagnus »

tabs_masterrace wrote: post #31
guessmyname wrote: post #5

I implemented more than a dozen OAuth integrations last year with multiple American and Chinese companies and oh boy it was painful. I do not know why so many engineers end up reading a clear specification document like RFC-6749 [1] and then ignore 80% of the instructions. I had to deal with so many weird bugs and bad OAuth server implementations, I lost count of how many emails went back and forth trying to make sen…

Oh man, I've done Google, Facebook, Reddit and all of them have tiny but annoying differences in their Auth Flow. I've given up up on Twitter, because they didn't even seem to support OAuth2 (maybe they do now?), but it was too much of a pain. What's also very annoying is the need to register an "application" at the provider. So i.e. for Facebook you have to login into their developer portal, create an app, fill out…

> "Don't know why this is necessary"

Ok so the other replies here clarify why — but really it'd have been nice if there was at least some consistent interface between all the OAuth / OIDC providers, so one wouldn't need to learn new interfaces all the time.

... And, worse, now I need to take screenshots and document all these different interfaces, for an open source project I'm building, whose users might want to register OIDC client apps too. :- /

Re: OAuth 2.0 Security Best Current Practice

#97

Post by ecnahc515 »

niftich wrote: post #62
anderspitman wrote: post #53

Earlier quoted context omitted.

Forgive me if I'm mistaken, but isn't OIDC for authentication/profile information? Does it include standards for things like accessing contact lists, reading/writing files, sending email, etc?

OIDC is for authentication and profile information. The standard claims refer to each field of profile information [1]. It doesn't include any domain-specific operations like your examples. [1] https://openid.net/specs/openid-connect-core-1_0.html#Standa...

A bit late: you're correct, but it does provide a standard API for looking up additional metadata, even if it's non-standard. That's using custom claims and/or the user info endpoint (which can include custom claims). You can use custom scopes to limit what is available as well.

Re: OAuth 2.0 Security Best Current Practice

#98

Post by ecnahc515 »

jcranmer wrote: post #47
ecnahc515 wrote: post #41

Earlier quoted context omitted.

There's a spec for dynamic registration of clients for Oauth2/OIDC if I recall correctly. There's a reason that you have to register, and it's because you're potentially obtaining information about users, and they need a way to be able to block specific (potentially malicious) clients using their IDP.

When I was looking up the OAUTHBEARER draft, there's a (OPTIONAL) field in the error response to point to the openid-configuration for dynamic registration. At the time I was implementing things for Thunderbird, no one was using this yet, and I would be surprised if this has actually been implemented by any major provider in any sort of usable way for clients.

Yeah no one uses it because they explicitly want you to authenticate to register the clients on the users behalf so they can lock you out if you abuse it. It's annoying, but it makes sense. Otherwise an abuser can just dynamically create new clients anytime their existing clientID is banned.
Post reply on HN