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

31–40 of 98 posts

Re: OAuth 2.0 Security Best Current Practice

#31

Post by tabs_masterrace »

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 all the stuff they want to know, and then rely on them to approve your app. You have to do this for each and every provider, and for each application you want to support, and of course they all have different developer portals and want to know varying amounts of information... I've given up on Instagram OAuth because it seemed to much hassle to get your application approved.

Don't know why this is necessary, there should be a simple straightforward spec solely for Auth, that doesn't require all these steps.

Re: OAuth 2.0 Security Best Current Practice

#32

Post by vwpolo3 »

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…

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

Re: OAuth 2.0 Security Best Current Practice

#33

Post by thinkharderdev »

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.

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.

Re: OAuth 2.0 Security Best Current Practice

#34

Post by [deleted] »

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…

[deleted]

Re: OAuth 2.0 Security Best Current Practice

#35

Post by segphault »

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…

It's not just an open source problem. It's fairly trivial to scrape the keys out of a lot of closed source applications. When Twitter first mandated OAuth, I was able to grep a key right out of the apk of their native Android client.

OAuth with client secrets is fundamentally unsuitable for desktop and mobile applications, but that hasn't stopped virtually every major implementor from using it that way. The people who wrote the spec were too busy congratulating each other and downplaying concerns to seriously engage with this issue until it was much too late to do anything about it.

It remains a deeply broken standard, and the people who were responsible for it at an early stage are entirely to blame. Several of them have removed their names from the spec, but I'll not forget the role they played in shouting down critics who raised concerns about this very issue.

Re: OAuth 2.0 Security Best Current Practice

#36

Post by niftich »

deng wrote: post #7
nicolaslem wrote: post #4

Earlier quoted context omitted.

From my understanding the best practice for applications that run on clients' machines (Javascript SPA, mobile app, email client) is to not use a client secret at all. Just use a client id and assume that anyone can reuse it. Of course that is if the OAuth provider allows it.

> Of course that is if the OAuth provider allows it. That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?

In this situation, their guidance says to embed the secret, because in this context it's obviously not a secret. Here's the current page [1]; here's the earliest Archive.org snapshot of its one-earlier predecessor page from 2015 [2] -- the advice has been consistent.

[1] https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developer...

Re: OAuth 2.0 Security Best Current Practice

#37

Post by krooj »

mooreds wrote: post #27
thecopy wrote: post #17

Earlier quoted context omitted.

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

Re: OAuth 2.0 Security Best Current Practice

#38

Post by malinens »

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

Re: OAuth 2.0 Security Best Current Practice

#39

Post by jimdigriz »

mooreds wrote: post #27
thecopy wrote: post #17

Earlier quoted context omitted.

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

This is solvable by use of a web worker as a key vault:

https://gitlab.com/jimdigriz/oauth2-worker

Re: OAuth 2.0 Security Best Current Practice

#40

Post by deng »

niftich wrote: post #36
deng wrote: post #7

Earlier quoted context omitted.

> Of course that is if the OAuth provider allows it. That's the catch. Last time I checked, at least Google didn't. So how can you write a (F)OSS email application for accessing GMail via OAuth2, without putting the secrets into the code (which Google also forbids)?

In this situation, their guidance says to embed the secret, because in this context it's obviously not a secret. Here's the current page [1]; here's the earliest Archive.org snapshot of its one-earlier predecessor page from 2015 [2] -- the advice has been consistent. [1] https://developers.google.com/identity/protocols/oauth2/nati... [2] https://web.archive.org/web/20150520223809/https://developer...

No, Google is not consistent in the slightest, because their terms of service directly contradict this statement:

"Developer credentials (such as passwords, keys, and client IDs) are intended to be used by you and identify your API Client. You will keep your credentials confidential and make reasonable efforts to prevent and discourage other API Clients from using your credentials. Developer credentials may not be embedded in open source projects."

From: https://developers.google.com/terms

Post reply on HN