OAuth 2.0 Security Best Current Practice • Hacker News Board

Re: OAuth 2.0 Security Best Current Practice

#61

Post by niftich » Tue, May 05, 2020, 10:19 PM UTC

polskibus wrote: post #18

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…

I always wonder why do companies have to implement oauth2/open id connect. It seems like a big waste in tech to spend so much time implementing the same things by different companies. can you tell me if there is a good drop in component that I can add to my product and integrate easily to get oauth2/open id connect? I heard good things about identity server but would appreciate if you could share your opinion on it.

A drop-in component so your product can do what exactly?

To be an OIDC Relying Party [1]?

To be an OIDC Provider [1]?

To be an OAuth2 client [2]? Keep in mind, being an OAuth2 client is probably not useful by itself -- you'll have to program your app to deal with the resource server's specific APIs to accomplish anything, and request the appropriate scopes for the situation, based on what you're doing.

[1] https://openid.net/specs/openid-connect-core-1_0.html#Termin... [2] https://tools.ietf.org/html/rfc6749#section-1.1

Re: OAuth 2.0 Security Best Current Practice

#62

Post by niftich » Tue, May 05, 2020, 10:29 PM UTC

anderspitman wrote: post #53

ecnahc515 wrote: post #43

Earlier quoted context omitted.

OIDC is basically a protocol, and is what you're describing. It's _the_ attempt to standardize on a common set of scopes, discovery mechanisms, etc for making it easier to build apps that use OAuth2.

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

Re: OAuth 2.0 Security Best Current Practice

#63

Post by [deleted] » Tue, May 05, 2020, 11:14 PM UTC

[deleted]

Re: OAuth 2.0 Security Best Current Practice

#64

Post by mooreds » Tue, May 05, 2020, 11:18 PM UTC

krooj wrote: post #37

mooreds wrote: post #27

Earlier quoted context omitted.

With the implicit grant? I read the RFC recently and thought it was only for the Authorization Code grant. From https://tools.ietf.org/html/rfc7636 "OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PK…

With PKCE you can use the authorzation_code grant flow. The whole issue with SPAs and the authorization_code grant flow isn't the presence or absence of middleware; rather, it's the lack of a confidential client. PKCE gets around the requirement for a client to securely store it's secret.

Right, but even after the authorization code flow, the access token is stored somewhere on the client.

My understanding is that that is suboptimal because the browser has such a large surface area to secure.

Re: OAuth 2.0 Security Best Current Practice

#65

Post by mooreds » Tue, May 05, 2020, 11:18 PM UTC

jimdigriz wrote: post #39

mooreds wrote: post #27

Earlier quoted context omitted.

With the implicit grant? I read the RFC recently and thought it was only for the Authorization Code grant. From https://tools.ietf.org/html/rfc7636 "OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PK…

This is solvable by use of a web worker as a key vault: https://gitlab.com/jimdigriz/oauth2-worker

That is very cool, thanks for sharing!

Edit: This seems pretty new, any timeline for a release?

Re: OAuth 2.0 Security Best Current Practice

#66

Post by dwaite » Tue, May 05, 2020, 11:21 PM UTC

anderspitman wrote: post #55

vwpolo3 wrote: post #32

Earlier quoted context omitted.

Don't implement your own, there's tons of open source that can do that, for example https://github.com/ory/hydra

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

Re: OAuth 2.0 Security Best Current Practice

#67

Post by zanny » Tue, May 05, 2020, 11:27 PM UTC

ecnahc515 wrote: post #43

anderspitman wrote: post #22

Earlier quoted context omitted.

At least one problem is that Oauth2 isn't a protocol; it's a framework for making protocols. Things like endpoints, scopes, security practices, etc aren't prescribed, so every implementation is different. And unfortunately none of the big players are really incentivized to standardize anything.

OIDC is basically a protocol, and is what you're describing. It's _the_ attempt to standardize on a common set of scopes, discovery mechanisms, etc for making it easier to build apps that use OAuth2.

And the platforms that do support OIDC properly just require a login portal URL to integrate support for it.

Want to add Microsoft logins with an oidc library? One url.

Want to add Twitter / Facebook signin? Go get an OAuth library and write several hundred LOCs to detail the scopes and crap you want form them because they are non-standard.

Re: OAuth 2.0 Security Best Current Practice

#68

Post by abhishektwr » Tue, May 05, 2020, 11:44 PM UTC

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 landscape [2]. At this stage, there are too many draft proposals and a majority of them led by vendors with some interest in standardizing their implementations.

For example, this RFC suggests restricting issued access token to one resource at a time (using audience parameter). Well with Microservices landscape this gets really challenging. Your client application may be interacting with multiple resources. Neither OpenID Connect nor OAuth 2.0 offer solutions to issue multiple access tokens (not yet). An API Gateway may be a solution but still so much ambiguity.

I think OpenID Community has done a better job to organize their specifications and working groups [3]. If you go on their specification page it tabulates really well what spec is final, currently under implementation, draft, or obsolete. Still, big vendors influence agenda and direction.

(Disclaimer: I am the founder of https://axioms.io/ which OAuth 2/OpenID Connect compliant identity management platform)

[1]: https://tools.ietf.org/html/rfc6819

[2]: RFC 6749, RFC 6750, RFC 6819, RFC 7662, RFC 7009, RFC 7519, RFC 8414, RFC 7591, RFC 7592, and 20 more.

[3]: https://openid.net/developers/specs/

Re: OAuth 2.0 Security Best Current Practice

#69

Post by niftich » Tue, May 05, 2020, 11:51 PM UTC

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…

As posted by someone downthread [1], there's an ongoing effort to update the OAuth 2.0 spec with changes since, lessons learned, and best practices [2], in what's currently being called OAuth 2.1. Some more rationale and resources on oauth.net [3].

[1] https://news.ycombinator.com/item?id=23083245 [2] https://tools.ietf.org/html/draft-parecki-oauth-v2-1-02 [3] https://oauth.net/2.1/

Re: OAuth 2.0 Security Best Current Practice

#70

Post by microtherion » Tue, May 05, 2020, 11:53 PM UTC

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…

One particularly nasty annoyance I've discovered recently is SoundCloud, which describes in great detail how to use their API and how to register applications, except when you actually try to do that, you discover that they "temporarily" disabled application registration several years ago and never re-enabled it.