alt Hacker NewsWhat Is OAuth?
Comments
As someone who has had to deal with OAuth quite a bit at work, I like it for the most part, but it's just so dang big and complicated.
Almost everyone thinks of OAuth as the "three legged redirect" flow, where one site sends you to another, you say "Yes, I authorize" and it sends you back, and now that site can act as you on that other site.
But that's just the tip of the iceberg! That's called the "authorization code" grant, because implementation wise the one site gives a special one time authorization code to the other one, which it can then exchange server-to-server to get the actual sensitive access credential.
What about if the human isn't in the loop at that moment? Well you have the "client credentials" grant. Or what if it's limited input like a TV or something, well then you have the "device" grant.
And what if the client can't securely store a client secret, because it's a single page web app or a mobile application? Then it has to be a public client, and you can use PKCE or PAR for flow integrity.
What if you can't establish the clients up front? There's DCR, which is all important now with MCP. But then that either lets unauthenticated requests in to create resources in your data stores, or needs to be bootstrapped by some other form of authentication.
It's all just a sprawling behemoth of a framework, because it tries to do everything.
The central paragraph of this is still really hard to parse:
"At its core, OAuth for delegation is a standard way to do the following:
The first half exists to send, with consent, a multi-use secret to a known delegate.
The other half of OAuth details how the delegate can use that secret to make subsequent requests on behalf of the person that gave the consent"
This paragraph has a bunch of words that need defining (the word delegate does not appear on the page until then) and a confusing use of 'first half', 'second half' .... First half of what?
Surely it can be explained better than that?
> Hopefully, this post helps clear that up!
Thanks, it did not.
OAuth and OpenID Connect are a denial of service attack on the brains of the humans who have to work with them.
The thing about OAuth is that it’s really very simple. You just have to grasp a lot of very complicated details (that nobody explains) first before it becomes simple.
Good description of OAuth from one of the folks there at the beginning. I think the author doesn't do a great job of answering the question in the concrete, though. This sibling comment does a lot better[0].
I'm partial to this piece[1], which I helped write. It covers the various common modalities of OAuth/OIDC. (It's really hard to separate them, to be honest; they're often.) Was discussed previously on HN[2].
0: https://news.ycombinator.com/item?id=47100073
1: https://fusionauth.io/articles/oauth/modern-guide-to-oauth
> What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design
Author managed to simultaneously praise the question and avoid answering it at all.
OAuth didn't make a lot of sense to me until I learned about RFC7517. JSON Web Keys allow for participants to effectively say "all keys at this URL are valid, please check here if not sure". The biggest advantage being that we can now rotate out certificates without notifying or relying on other parties. We can also onboard with new trusted parties by simply providing them a URL. There is no manual certificate exchange if this is done all the way.
I am seeing many fintech vendors move in this direction. The mutual clients want more granular control over access. Resource tokens are only valid for a few minutes in these new schemes. In most cases we're coming from a world where the same username and password was used to access things like bank cores for over a decade.
The oauth2-proxy suggestion above is probably the easiest path for this. The main thing to watch out with nginx-level oauth is token expiry. If you set short-lived tokens (which you should), you need the proxy layer to handle refresh silently or your friends will keep getting kicked back to the login screen mid-session. If you just need Google or GitHub login for a few people, oauth2-proxy with an email allowlist is way less overhead than running a full identity provider.
https://youtu.be/996OiexHze0?is=5OPbjDzeMAo-UmNE
A classic explainer from almost a decade ago. This explains it from the point of view of the original problem it was designed to solve.
In case anyone is wondering how to scroll: your mouse needs to be in the center of the page, not in the margins.
If you'd like to quickly understand OAuth, I found this guide to be very helpful: https://alexbilbie.github.io/guide-to-oauth-2-grants/
I've been meaning to set up some nginx-level oauth. I have some self-hosted apps I want to share with friends / family but forcing them to remember a user / pass (basic auth) or run a vpn is a bit too much friction.
OAuth has always been quite hard to grasp, even though I use it every day. One day I'll write an implementation to properly understand how it works from the bottom up and go through each of the standards that have evolved over time.
> There are very credible arguments that the-set-of-IETF-standards-that-describe-OAuth are less a standard than a framework. I'm not sure that's a bad thing, though.
Spoiler alert: it is.
Its looks simple, sounds simple, however its not. Merging(Being hijacked by) authorization into authentication is probably the slippery slope.
For me, OAuth was straightforward to understand once I realised that it's basically like a PKI with very short-lived certificates.
Pain. Thanks for asking.
I thought I knew what OAuth was (we actually use it in several projects) until I read this “explanation”. If this was supposed to clarify anything, well, it didn’t.
In homelab, I push myself to use proxy (header) authentication. I know I'm burdening many responsibilities in a reverse proxy (tls, ip blocking, authentication) but it seems I can better handle those complexity as compared to oauth setup.
The title of the post, which the submitter dutifully copied, is IMHO unfortunate since the post seeks to answer the following question:
What I need is to understand why it is designed this way, and to see concrete examples of use cases that motivate the design
It's not "just another" explanation for how OAuth does, which was my immediate guess when reading the title.
However glad I opted to give it a chance, and likely especially illuminating for the younger crowd who didn't get to experience the joys of the early web 2.0 days.
If you go to most Fortune 500 companies they will have a whole team of people dedicated to running an IdP and doing integrations. Most people on these teams cannot explain oauth, oidc, or saml even though they work with it every single day. It’s that bad.
What helped me get a better understanding of oauth and oidc, was this YouTube video [0].
I’m one of the few I guess that have implemented OAuth at scale and enjoy it more than other forms of auth. Remember Windows Login Auth? Or each system having to be sync’ed to some sort of schedule so that passwords were the same? Yeah, no, that sucks.
OAuth is just a process framework for doing authentication and authorization such that a system doesn’t need to create those mechanisms themselves but can ask a server for it. More recently, in the form of a JWT token with those permissions encoded within.
It all boils down to how long your login token (some hash), or in the case of OAuth, your refresh token, can request an access token (timeboxed access to the system). “Tokens” in this case are just cryptographic signatures or hmac hashes of something. Preferably with a nonce or client_id as a salt.
Traditional login with username and password gives you a cookie (or session, or both) that you use to identify that login, same thing for refresh tokens. Only, refresh tokens are authentication, you need access so you request an access token from a resource server or api, now you have your time boxed access token that allows you to “Authentication: Bearer <token>” at your resource.
From a server perspective, your resource server could have just proxied the username and password auth to get the refresh token or (what I like to do) check the signature of the refresh token to verify that it came from me. If it did, I trust it, so long as the user isn’t in the ban table. If it’s good and they aren’t banned, issue them a time boxed access token for 24h.
If you fail to grasp the JWT aspect, I suggest you learn more about RSA/PKI/SHA and HMAC encryption libraries in your programming language of choice. Knowing how to bcrypt is one thing, knowing how to encrypt/sign/verify/decrypt is The Way.
(Sorry to the grey beards in the back and they know this already and probably wrote that RFC).
Terrible explanation what Oauth is. But the insight at the end of the article is great. UX should always be the driving factor.
I've seen so many integrations use Oauth where it wasn't a good fit or where the spec was not followed. It always results in an abomination and insecure mess.
Maybe it's a know the rules before you can break them thing, but I've found designing custom auth integrations from UX first perspective result in amazing features. It's rare that both parties are willing to put the effort in it though. Usually people try to shoehorn the usecase into an existing oauth platform.
The main selling point of Oauth is to scale auth and authz to thousands of clients and use cases.
no offense but it looks like the reason behind oauth confusion is the author. I had to read half way through to get to a definition which was a poor explanation. Sometimes certain topics are difficult to understand because the initial person behind it wasn't good at communicating the information.
It's something many people use, but many of them don't know what it is. Thanks for this article.
Great writeup
[flagged]
This is the only thing you need to know about OAuth. As FYI ...Eran Hammer is the author of OAuth 1.0 and original editor of the OAuth 2.0 spec.
[1] "...Eran Hammer resigned from his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specification in July 2012. Hammer cited a conflict between web and enterprise cultures as his reason for leaving, noting that IETF is a community that is "all about enterprise use cases" and "not capable of simple". "What is now offered is a blueprint for an authorization protocol", he noted, "that is the enterprise way", providing a "whole new frontier to sell consulting services and integration solutions". In comparing OAuth 2.0 with OAuth 1.0, Hammer points out that it has become "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure". He explains how architectural changes for 2.0 unbound tokens from clients, removed all signatures and cryptography at a protocol level and added expiring tokens (because tokens could not be revoked) while complicating the processing of authorization. Numerous items were left unspecified or unlimited in the specification because "as has been the nature of this working group, no issue is too small to get stuck on or leave open for each implementation to decide."
David Recordon later also removed his name from the specifications for unspecified reasons. Dick Hardt took over the editor role, and the framework was published in October 2012.
David Harris, author of the email client Pegasus Mail, has criticised OAuth 2.0 as "an absolute dog's breakfast", requiring developers to write custom modules specific to each service (Gmail, Microsoft Mail services, etc.), and to register specifically with them."
[1] https://en.wikipedia.org/wiki/OAuth