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.
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.
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.
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.
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.
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.
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 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?
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.
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.
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.
> 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.
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."
34 comments
[ 3.4 ms ] story [ 56.8 ms ] threadWhat 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.
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.
[0]: https://youtu.be/996OiexHze0
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).
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.
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.
"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?
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.
Spoiler alert: it is.
[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