Everything you need to know about OAuth 2.0 | Hacker News Reader

Everything you need to know about OAuth 2.0

gravitational.com

207 pointstwakefield28 comments

Probably this introduction is good for some purposes but for me it is too informal and too far from (my) reality. I would say it is 90% identical to many other introductions to OAuth.

I have been trying to comprehend and formulate the main idea behind the usage of this technology, for example, as follows:

    OAuth allows us to use surrogates (like JWT) instead of the original credentials (like name and password) with the main benefits that once it is available, the original credentials are not needed anymore: neither by the client nor by the server

Why it is the central idea? Because we do not consider where and how the tokens are obtained: you can get it by USB stick or maybe forge somehow artificially. It is important only that access to resources requires a special piece of data rather than (traditional) credentials. The main question for the client is whether the server will accept this token or not. For the server, the main question is whether it can trust this client and its tokens.We aslo abstract from what is inside this token and how the server decides what to do - these are considered details.

Do I miss something more important?

The mechanism of refresh token is also important. You can have a token with a short lifetime, so if someone stole this token, he won't have an infinite access to your data. Of course, this would also be possible with credentials, but you would have to store them (risky) or ask them to the user every 20 minutes (annoying).

Something I’ve never really got about refresh tokens is how they improve that situation - I have difficulty seeing a situation where the access token can be compromised but the refresh token can’t, and with a refresh token you’re free to request new access tokens indefinitely.

In a complex application I'd rather send a very short lived and tightly scoped token to a service written by another team or another company that I know less about.

If the service handling your access token has some security issues (old version of x y z, etc) there is limited damage if nefarious actors acquire that token. They could not keep your session alive, spread horizontally, etc. Also, you can make access tokens very short lived to minimize the window of opportunity, should someone acquire one.

Then I can concentrate on my "session service" (the thing issuing tokens) to be very secure, and tune the characteristics of either token as needed.

I think it's more like when you use the refresh token, there's a surface area of attack - lets say it's a login server. If the login server is the only one to ever get refresh tokens, then that's the only surface area where refresh tokens can be breached, audited, etc.

Every other API gets a short lived access token. While that also needs to be secure, the vulnerabilities of that become different. Eg if your logs printed your access tokens, and after 30 days you moved them to S3, no one could read the S3 logs and log into your service. Probably a terribly insecure example but i think it illustrates the different vectors to be concerned about. Refresh tokens vs Access tokens just have different surface areas to be concerned about.

Thanks, that makes a lot of sense - I was thinking in terms of the ultimate client application being compromised, which isn't helped by refresh tokens, but hadn't considered that services along the way don't ever see those tokens.

Hello, author here. First off, thank you for taking the time to read this.

The original draft started out much more technical than this version, but it was simplified to read less like a whitepaper. In the original draft, I discussed the Authorization Code Grant with the PKCE extension, which is for public clients (clients that cannot be trusted):

  "The barebones authorization code grant is used for server-side applications, where confidential clients are trusted with a secret. By using the PKCE (Proof Key for Code Exchange) extension, this same flow can be used with public clients like browsers or mobile applications. The only modification to this flow is cryptography.

  1. Client generates a random string of length 43-128 characters and turns it into a URL-safe 256 hash. Other hashing methods can be used

  2. Client directs the resource owner to sign into the authorization server. The hashed string is included as a parameter in the query

  3. Resource owner signs in and approves client, then redirects back

  4. Client makes an HTTPS POST request for a token. Included is the unhashed randomly generated string

  5. Authorization server hashes this string with the same hashing method (SHA256) and compares its calculated hash to the hash received in step 2. If the hashes match, and access token is issued

  The trick here is knowing that the odds of two hashes with different inputs being the same are infinitesimally small and can be ignored. If even one character is different in the input, the outputted hash will be entirely different. By sending the hash in step 2 and then the original input string in step 4, the authorization server can verify it is still communicating with the authorized client by comparing what it received to what it produced. Any fraudulent client would have no way of knowing what the input string is."

Applications must not be given passwords. Consider that there are hundreds of applications/api/reports in a company, managed by hundreds of developers in different departments.

Passwords would be leaked all over the place (verbose logging, debugging to investigate issues, etc...). That's totally compromising employees/users, as passwords are rarely changed and reused for personal accounts.

This also has a very nice and simple explanation of the whole thing:

https://www.youtube.com/watch?v=996OiexHze0

It's about 1h long, but it's really worth it.

Agreed. I recommend this video to every new dev joining our team.

Thank you for sharing this.

This introduction is pretty simple and concise to just understand what it is: https://www.cloudflare.com/learning/access-management/what-i...

Follow that up with this SAML and OAuth comparison: https://www.ubisecure.com/uncategorized/difference-between-s...

Then see how OpenID Connect fits in: https://www.okta.com/identity-101/whats-the-difference-betwe... https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/

And this page shows examples of a web app using OAuth2: https://connect2id.com/learn/oauth-2

I like these explanations a lot, they were super useful when I had to dig deep on OAuth2 and OIDC

https://connect2id.com/learn/oauth-2

Connect2id and OAuth.net were great resources. But unless you were already familiar with the topic, they were a bit difficult to follow. That's why I started this article with some analogies!

Is it possible to "shell" or abstract an oauth2.0 server app into an oidc provider?

The main usecase for this would be allowing applications like kibana/elasticsearch (which only has support for open id), talk with those auth server apps that have only oauth2.0 support...

I still have some more research to do for the OIDC article, but in theory, yes. OIDC runs as an identity layer on top of OAuth. The only thing that makes OIDC unique is that there's a widely accepted "scope" that provides standardized ID information, which is bundled into an ID token and sent with the access token. So there's no reason two applications that are built on the same protocol can't communicate.

Good question, I'll include it when I write the next one.

Kibana supports SAML. At east in the Elastic cloud offering.

https://www.elastic.co/blog/how-to-enable-saml-authenticatio...

Does SAML and OAuth2.0 work together?

We have an SSO server implementing OAuth2.0. We want this to be the basis for logging into elasticsearch/kibana.

PS: we are currently tinkering with the Opendistro version of elasticsearch.

I'm an experienced programmer and I've never found anything harder to work with than OAuth 2.0. Every project I work on, there's a two week "WTF" while we figure out all the details.

it's been a while but I remember being confused until I read the rfc itself. The rfc is actually clear and straightforward.

When implementing an identity solution for my former employer, I ended reading basically every RFC in this space. I found them really confusing the first time through, but the second time I sat by a whiteboard and drew out the sequences and it all started to click.

That being said there are a bunch of RFCs and it's not always totally clean how they fit together. Or in the case of implementing your own IdP, which ones you need to really care about.

The OAuth2 RFC and almost every associated guide on the Internet was way too vague for me to understand, but reading the OIDC spec was amazing, makes things very clear.

For what I understand about OAuth, I don't see how it solve the privacy problems. The Authorisation Server is aware of all client requests made on behalves of the user, therefore giving a rich profile of user interests.

Am I missing something?

Anyone can recommend me a SMTP server that don't require oauth2? Currently my company use GSuite but oauth2 will be mandatory, but the open source projects we use as base for our internal software won't support it (because they can't get the certifications).

Not sure if I understand your question completely but Fastmail lets me send SMTP using simple authentication.

Awws SES, sendgrid?

The enterprise world is 10y behind, and OAuth is the incremental change we can forsee being adopted by them. This is really valuable.

Check this out https://devansvd.com/oauth

Reply on news.ycombinator.com