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

41–50 of 98 posts

Re: OAuth 2.0 Security Best Current Practice

#41

Post by ecnahc515 »

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…

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.

Re: OAuth 2.0 Security Best Current Practice

#42

Post by deng »

dwaite wrote: post #19
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)?

The conversation I had with a Google engineer implied the appropriate course of action was to embed the secret. https://github.com/openid/AppAuth-JS/issues/46

The Google engineer should read Google's terms of service which explicitly states that you may not do that (see my reply above).

Re: OAuth 2.0 Security Best Current Practice

#43

Post by ecnahc515 »

anderspitman wrote: post #22
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.

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.

Re: OAuth 2.0 Security Best Current Practice

#44

Post by mooreds »

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.

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

Re: OAuth 2.0 Security Best Current Practice

#45

Post by DCKing »

dijital wrote: post #2

Worth bearing in mind: > This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. > ... > It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

As a case in point: https://tools.ietf.org/html/draft-wkumari-not-a-draft-05

I think publishing an IETF RFC on security best practices is hard, but I hope these authors manage to pull through

Re: OAuth 2.0 Security Best Current Practice

#47

Post by jcranmer »

ecnahc515 wrote: post #41
tabs_masterrace wrote: post #31

Earlier quoted context omitted.

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…

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.

Re: OAuth 2.0 Security Best Current Practice

#48

Post by maxchehab »

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 work at WorkOS (we handle Enterprise SSO among other things, https://workos.com). We interface many... should I say "less elegant"... enterprise identity protocols with an OAuth api. There is support for common identity providers such as Azure, AD FS, Okta, VMware, to name a few. If you'd like access to our beta send me an email (max@workos.com) and mention hn.

Re: OAuth 2.0 Security Best Current Practice

#49

Post by niftich »

segphault wrote: post #35
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 wh…

Much of the deployment of OAuth2 was a shitshow, because early on, there was a huge debate about OAuth1 vs OAuth2, and the concepts and terminology used in the OAuth2 spec exceeded the mental load of people who were simply looking for a quickstart to some API. Docs by various providers either adopted the OAuth2 terminology wholesale without sufficiently explaining the new concepts and the best practices, or they simplified the client registration to just a few fields and offered no guidance as to make use of them in your app.

The spec has been clear from the start that there are clients that can protect their secrets, and ones that can't [1]. Here's a choice quote: "A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted." Unfortunately, much of the rest of the spec is a bit like a playing puzzle, where reading it in one sitting doesn't actually build your understanding, and you have to constantly cross-reference various sections to construct a complete picture of the process the spec is trying to set.

It look a long time for people's familiarity with the spec to grow, and for providers and clients to improve in quality and adherence to the ideas and text of the spec.

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

Re: OAuth 2.0 Security Best Current Practice

#50

Post by batter »

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.

Company i work in spent 2 years to implement OAuth. For that time application was rewritten 3-4 times. 3 developers worked on that in different times. And guess what? It still doesn't work and serves tiny portion of traffic with tons of issues.
Post reply on HN