OAuth 2.0 Security Best Current Practice • Hacker News Board

Re: OAuth 2.0 Security Best Current Practice

#21

Post by bingo_cannon » Tue, May 05, 2020, 6:38 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.

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.

Re: OAuth 2.0 Security Best Current Practice

#22

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

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.

Re: OAuth 2.0 Security Best Current Practice

#23

Post by anderspitman » Tue, May 05, 2020, 6:49 PM UTC

> 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 simply a non-starter for my application.

It would be nice if there was an escape hatch for developers who understand the risks. More background in this SO question I asked a couple days ago:

https://stackoverflow.com/q/61563348/943814

Re: OAuth 2.0 Security Best Current Practice

#24

Post by anderspitman » Tue, May 05, 2020, 6:54 PM UTC

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 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, deletions, and best practices. So I just skipped the specs, and have been using resources like this, Oauth2 Simplified, and of course YouTube.

So I guess the upshot is I find resources like this and the upcoming 2.1 to be valuable.

Re: OAuth 2.0 Security Best Current Practice

#25

Post by BiteCode_dev » Tue, May 05, 2020, 7:00 PM UTC

deng wrote: post #3

To this day I have no idea how one should handle client secrets in (F)OSS applications, and I'm often wondering if I'm the only one. I guess what this text says in 4.13 is "just don't put it somewhere for anyone to see", which means that the only solution is to make the id and secret configurable and let the user register the application with its OAuth provider, which of course most users wouldn't know how to do. As…

Usually you put a service that hold the key, and the client application ask the service to do the request for it.

If the user doesn't want to use your service, they configure their own key.

Re: OAuth 2.0 Security Best Current Practice

#26

Post by anderspitman » Tue, May 05, 2020, 7:01 PM UTC

tptacek wrote: post #16

mooreds wrote: post #14

Earlier quoted context omitted.

Were you implementing a client in all of these OAuth integrations? I thought the point of OAuth was to make it easy to build clients and push the complexity to the authorization servers :) ?

Whatever the intentions may have been, it is definitely not the case that OAuth pushes complexity to authorization servers. My audit checklist for OAuth clients is fairly long.

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.

Re: OAuth 2.0 Security Best Current Practice

#27

Post by mooreds » Tue, May 05, 2020, 7:03 PM UTC

thecopy wrote: post #17

mooreds wrote: post #13

Earlier quoted context omitted.

Sorry, I misspoke. Those SPAs always have middleware to handle the authorization code, right? It's really the implicit grant (where access tokens are available to the client) that should be avoided.

No, with PKCE you can do auth code from an SPA

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 (PKCE, pronounced "pixy")."

At the end of the day, no matter what the grant, if you store the access tokens (or refresh tokens) in the browser running an SPA, it is vulnerable to an XSS attack, right?

Re: OAuth 2.0 Security Best Current Practice

#28

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

anderspitman wrote: post #24

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

2.1 will hopefully be a one stop shop for implementors. At least, when I was writing a post about OAuth 2.1, that was the intention of the authors, from what I read on the mailing list.

Re: OAuth 2.0 Security Best Current Practice

#29

Post by mooreds » Tue, May 05, 2020, 7:09 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.

(Full disclosure, FusionAuth is my employer.)

If you want a drop in OAuth/OIDC server that runs anywhere, I'd recommend looking at FusionAuth. You can set it up in 5 minutes and it runs everywhere: https://fusionauth.io/docs/v1/tech/5-minute-setup-guide

Worth noting: it is free as in beer--if you need an open source solution, it's not a fit.

Edit: typo

Re: OAuth 2.0 Security Best Current Practice

#30

Post by mooreds » Tue, May 05, 2020, 7:09 PM UTC

anderspitman wrote: post #26

tptacek wrote: post #16

Earlier quoted context omitted.

Whatever the intentions may have been, it is definitely not the case that OAuth pushes complexity to authorization servers. My audit checklist for OAuth clients is fairly long.

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.