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.
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.
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.
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.
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.
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.
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!
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.
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.
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).
I have been trying to comprehend and formulate the main idea behind the usage of this technology, for example, as follows:
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?