Live data from Hacker News

OAuth 2.0 Security Best Current Practice

tools.ietf.org

71–80 of 98 posts

Re: OAuth 2.0 Security Best Current Practice

#71

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.

[deleted]

Re: OAuth 2.0 Security Best Current Practice

#72
post #69

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/

Thanks for the pointer. I am not sure if OAuth 2.1 is part of working group yet. Nonetheless, a good consolidated read compared to reading 20 different RFC specs.

Re: OAuth 2.0 Security Best Current Practice

#73
This is all good and useful, but I wish OAuth folks would fix the bugs in the spec like, e.g.

"The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client."

This sounds reasonable on the surface, and technically it might be correct (depending on your interpretation of the words). But if someone naively follows this instruction to implement the server - issue a new refresh token and revoke the old one in the same refresh request at the server, what happens is when the client doesn't receive the new refresh token due to any transient failure, the client effectively loses its authorization, since the old refresh token is revoked and they didn't get the new one. Thus the protocol becomes "leaky" - you lose users because of transient errors.

i.e. "after issuing a new refresh token to the client" needs to be "after the new refresh token is being used at least once", or otherwise invent some other way to ensure the new refresh token is correctly received at the client before revoking the old.

Re: OAuth 2.0 Security Best Current Practice

#74
post #44

Earlier quoted context omitted.

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.

Any recommendations or favorites, and any to avoid?

Re: OAuth 2.0 Security Best Current Practice

#75

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…

This is why Nylas.com exists now.

Re: OAuth 2.0 Security Best Current Practice

#76
If there was one perfect way to do third-party auth, we wouldn't need a standard, because all the big companies would be doing it, and the smaller companies would do it.

The problem is, there's a bunch of decisions with auth, which have to be made, but aren't really important. What should the name of the auth token header be? What should be the format of the responses? These decisions are like deciding what side of the road to drive on: it doesn't matter which side of the road you drive on, as long as everyone drives on the same side of the road. The function of a standard is to decide what side of the road everyone drives on.

OAuth isn't a standard. It's just a description of all the various homegrown third-party auth systems that anyone has implemented over HTTP, with only the absolute worst patterns weeded out. None of the shareholders wanted to re-implement their third-party auth, so they just made sure their flavor of auth made it into the standard. It's like if the Europeans and the Americans got together to standardize the side of the road that everyone drives on, and the standard they came up with is "You have two options for which side of the road to drive on, the right or the left."

Until a group of visionaries with enough clout to make the world fall in line creates an actual standard, OAuth is going to continue to be crap. And there's strong disincentive to do that: if you agree to conform to a standard that isn't exactly what you've already implemented, then that means you have to reimplement. A few years' pain conforming everyone to a standard would significantly drive humanity forward--an incomprehensible amount of developer hours have been spent writing custom OAuth integrations, and an actual standard would allow us to write libraries around it that everyone could use. But corporations don't care about pushing humanity forward when it's contrary to their bottom line.

Re: OAuth 2.0 Security Best Current Practice

#77

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 think in addition to a spec, an official test suite that's used to certify an implementation as compliant would also greatly help.

Re: OAuth 2.0 Security Best Current Practice

#78

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.

I've been usjng keycloak as an UMA authorization server, and while it's better than nothing it has a few bugs that make it not exactly compliant with the spec. Additionally the UI is incredibly confusing and the documentation isn't that helpful in some cases. Anything you want to do you have to spend too much time searching the UI and some things are not even available: Want to assign ownership of a resource to a user? Need to run a curl request. Though I haven't tried other implementations, so maybe this one's the best

Re: OAuth 2.0 Security Best Current Practice

#79
I've been working with OAuth 2 for 7 years and I still don't really understand all the dark corners of the spec. Good to see Resource Owner grant type get called out for a "Do not use", although I dont think using it in a private, server side context is off the cards...

Re: OAuth 2.0 Security Best Current Practice

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

Do you have any examples of this?
Post reply on HN