OAuth 2.0 Security Best Current Practice • Hacker News Board

Re: OAuth 2.0 Security Best Current Practice

#51

Post by anderspitman » Tue, May 05, 2020, 9:45 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…

Technically unregistered clients are within spec. IndieAuth is one such implementation, focused on federated services. Aaron Parecki has a good writeup here[0]. Unfortunately that's not going to help you when playing with the big boys.

[0]: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

Re: OAuth 2.0 Security Best Current Practice

#52

Post by znpy » Tue, May 05, 2020, 9:45 PM UTC

Since we're talking oauth/openid: does anybody know if there's a way to get the OpenID spec in a format that is nicely formatted for printing?

(ideally, just like rfc 6749...)

Re: OAuth 2.0 Security Best Current Practice

#53

Post by anderspitman » Tue, May 05, 2020, 9:48 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.

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?

Re: OAuth 2.0 Security Best Current Practice

#54

Post by znpy » Tue, May 05, 2020, 9:49 PM UTC

bingo_cannon wrote: post #21

polskibus wrote: post #18

Earlier quoted context omitted.

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.

I've recently tried out Keycloak( https://www.keycloak.org/ ) and have been impressed with it. Saved at least a few weeks on a personal project. It does have a learning curve though.

This, so much.

I've been tasked with implementing oauth/openid at work and in about one month in spare time i was able to read rfc 6749, install keycloak, configure it, create a client, create a very basic app (~80 lines of python and flask) and log in via oauth/openid with user information and groups pulled via LDAP.

Keycloak is really a game changer.

This presentation is very interesting: https://www.youtube.com/watch?v=FyVHNJNriUQ

Re: OAuth 2.0 Security Best Current Practice

#55

Post by anderspitman » Tue, May 05, 2020, 9:52 PM UTC

vwpolo3 wrote: post #32

anderspitman wrote: post #24

Earlier quoted context omitted.

I can only give my perspective, which is likely to be unique. I'm in the process of implementing an Oauth2 server for the first time. I feel like I have a handle on it now, but it was definitely overwhelming at first. If I were confident that RFC6749 had everything in it that I needed, I would read through and implement it. But it quickly became apparent that there are a dizzying array of RFCs with extensions, deleti…

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 users are familiar with the flows.

Re: OAuth 2.0 Security Best Current Practice

#56

Post by niftich » Tue, May 05, 2020, 9:56 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…

Client registration is so that (1) the authorization server can obtain the client type (confidential or public), then, (2) if appropriate, obtain the client's Redirection Endpoint URI, so that the authorization server's authorization endpoint can avoid needing to be an open redirector, and (3) to obtain any metadata that the authorization server will display to the resource owner just prior to them approving or denying the authorization request. The spec explains this [1].

Also, service providers who are custodians of the resource owners' data want you to be accountable to them and their users, so they want to have some information about you.

There's a proposed standard for dynamic (and/or programmatic) client registration [2]. While there are some interesting use-cases, it offers little benefit to a service provider who wants to vet clients (or appear as if it did).

The spec contains some design recipes if you want a loose association between which clients are allowed to receive data the user approved (i.e. implicit grant), if you care little about whether the user trusts your app (i.e. resource owner password credentials grant), or if you care little about user approval (i.e. client credentials grant). The catch is that your unilateral opinions are insufficient: the client and service provider need to be in agreement about whether these are okay to use.

And, as is often the case with "kitchen sink"-type specs, these other usage modes muddy the waters around the safer and saner usage modes, so much of the current advice on OAuth2 focuses on dissuading their use.

[1] https://tools.ietf.org/html/rfc6749#section-2 [2] https://tools.ietf.org/html/rfc7591

Re: OAuth 2.0 Security Best Current Practice

#57

Post by [deleted] » Tue, May 05, 2020, 9:58 PM UTC

malinens wrote: post #38

anderspitman wrote: post #23

> Clients MUST NOT pass access tokens in a URI query parameter I've been wondering about this lately. This makes sense from a security perspective, but the primary alternative is setting a header like Authorization: Bearer, which makes your request subject to browser cross-origin restrictions, and all the fun that comes with CORS. In my case, the extra round-trip required for the CORS preflight in this situation is s…

put it in a cookie (secure samesite) or in request body

[deleted]

Re: OAuth 2.0 Security Best Current Practice

#58

Post by skrtskrt » Tue, May 05, 2020, 10:02 PM UTC

thinkharderdev wrote: post #33

polskibus wrote: post #18

Earlier quoted context omitted.

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.

Keycloak is a great open source identity server that supports openid connect. Works out of the box but also allows for full customization as well. Whatever you do, don't write your own oauth server.

Hydra looks like another popular open source solution, but it leaves you to implement the user login and challenge.

I have been writing a hobby OpenID server as a way to learn Go and to understand auth. Reading the OpenID connect spec is SO much more educational & clearer than the OAuth RFC on its own.

Re: OAuth 2.0 Security Best Current Practice

#59

Post by anderspitman » Tue, May 05, 2020, 10:06 PM UTC

malinens wrote: post #38

anderspitman wrote: post #23

> Clients MUST NOT pass access tokens in a URI query parameter I've been wondering about this lately. This makes sense from a security perspective, but the primary alternative is setting a header like Authorization: Bearer, which makes your request subject to browser cross-origin restrictions, and all the fun that comes with CORS. In my case, the extra round-trip required for the CORS preflight in this situation is s…

put it in a cookie (secure samesite) or in request body

Can you give more details on how you'd use a cookie here? SameSite=Strict/Lax can't be used cross domain, and none is no good for mutating requests due to CSRF.

Request body works, but it forces you to split your API if you want to be cache friendly. What I mean is ideally you want public data to be GETable and thus cacheable. In the system I'm building, any given path can change back and forth from being public vs requiring authorization, so if I use requests bodies (ie POSTs), I would need to detect whether the data is public or not before making the request and choose between GET or POST at request time. That might not actually be that bad; I'll have to think about it more.

Re: OAuth 2.0 Security Best Current Practice

#60

Post by Zenst » Tue, May 05, 2020, 10:07 PM UTC

mooreds wrote: post #30

anderspitman wrote: post #26

Earlier quoted context omitted.

As someone in the early stages implementing Oauth2 for the first time, I would be interested in seeing that list, if you don't mind sharing.

Agreed, I'd love to read that blog post.

Or Book/booklet, I'd buy that as I'm sure many would.

Indeed, there are some people when it comes to best practices, that I respect more than industry standards as they are usual best practices that will be standard tomorrow.