Because OAuth 2.0 sucks and got all bloated. The 1.0 version worked great for everybody but super big companies like google and facebook. But then big companies came in and made it a bloated standard that doesn't meet the needs of most users.
Why is OAuth still hard in 2023?
81–90 of 290 posts
Re: Why is OAuth still hard in 2023?
#82Earlier quoted context omitted.
It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token. It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters. I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in y…
> and one needs quite literally 10 minutes to read the RFC rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it. Never mind that there are several other OAuth RFCs.
You need 10 minutes of focused reading to understand what the purpose of the protocol is and you don't need all of the OAuth RFCs to implement the bare-minimum nor do you have to support all the grants available.
Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into.
Or, you can, you know - nitpick and live in the world of gloom and doom where everything sucks.
Re: Why is OAuth still hard in 2023?
#83I found this tool useful for debugging Oauth: https://github.com/cloudentity/oauth2c
Re: Why is OAuth still hard in 2023?
#84Authentication is easy and solutions are more or less fungible, but there’s no obvious and easy way to do authorization. OAuth makes authentication pretty easy but all the complexity comes from authorization, which is adjacent to authentication but not directly related to it. Although it’s not OAuth’s job to help you with authorization, it’s an inevitable next step that leads to massively divergent approaches
Re: Why is OAuth still hard in 2023?
#85It'd be interesting to hear about people who have had a good time implementing OAuth, as my experience is similar to that in the article. I've played with adding it to a few side projects and the process usually goes: 1. Read loads of docs, end up pretty confused 2. Find a library that seems to do what I want 3. Install this huge library full of opaque code doing...things 4. Have an impossible time troubleshooting is…
We really deserve a less over-engineered actual standard that has a very restricted feature set. In practice, isn’t OAuth predominantly used to verify proof of email ownership? If so, why not just use magic links as sign up & sign in? 1. Sign in/up: Enter email (can be pre-filled by browser/app) 2. Click the email verification link or enter code if on different device. 3. Profit. No manual typing necessary, only clic…
It would simply not handle pretty much any case that I have used OAuth2 to implement so far.
For example - login system that merged LDAP/Kerberos/client cert/long-lived application token authentication into single system, that also linked said authentication system into all applications in the network, including making it possible to login to AWS Console using Kerberos (that one was twisty to get running, not because of OAuth2 but because of how it is handled by AWS IAM).
Also, I have used it to link in MFA systems of different kinds (it was definitely easier side than industry standard of using Radius)
In addition, this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds, especially today when sending to arbitrary public emails.
Re: Why is OAuth still hard in 2023?
#86I don't know why it's still hard, but I can tell you, from the perspective of trying to prototype something, I would love to not have to use it just to find out if this functionality I want to build is worthwhile. I don't want to have to create a client, get some keys, worry about refresh tokens, etc. I want to hit an endpoint with an easily accessible token and get some data.
Make it so that the token is only valid for 30 days or something and then it requires moving to OAuth. But for prototyping stuff with curl and bash scripts, it's a giant pain.
Re: Why is OAuth still hard in 2023?
#87Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…
One reason is that the protocol itself is more complicated than you've described. For example, Google won't give you a long-lived access token. You need a refresh token, and then you use that to retrieve access tokens, and continue doing that as they expire. Why? I have not a flipping idea. Please, HN enlighten me how refresh/access token dichotomy improves the API.
It's really trying to solve a problem they created by statlessly handing out tokens instead of keeping session state on the backend - they have no way to revoke a token once issued, so long lived tokens are a liability. Solution? More complexity! Hand out very short lived tokens, along with a slightly longer lived refresh token, which only allows you get a new bearer/access token.
Re: Why is OAuth still hard in 2023?
#88Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…
One reason is that the protocol itself is more complicated than you've described. For example, Google won't give you a long-lived access token. You need a refresh token, and then you use that to retrieve access tokens, and continue doing that as they expire. Why? I have not a flipping idea. Please, HN enlighten me how refresh/access token dichotomy improves the API.
Very simple, actually. Access tokens are short-lived and are irrevocable - google services only check validity and expiration of those tokens.
Refresh tokens are more like session tokens/cookies - those get checked every time. At Google scale, checking it probably expensive, so they are using refresh tokens.
These aren't for end-user or development experience, those are for AS performance.
Re: Why is OAuth still hard in 2023?
#89As a web dev next auth makes auth a breeze just add a provider and go (unaffiliated, just love how easy its made things).
Re: Why is OAuth still hard in 2023?
#90Is there any good way to do OAuth on a headless system? I want to be able to run batch jobs without a browser involved. There's OAuth for devices but that has limited real world use.
Yes, multiple.
You can implement client credential mode - this means storing a credential and using it to acquire a token from OAuth2/OIDC provider, then using that token as Bearer Token in your API calls.
EDIT: I can add that I have implemented client credential mode in what was effectively raw PowerShell and similarly it can be done with curl from any shell script, even pretty dumb ones. Just do a single POST containing the necessary JSON structure to your OAuth2/OIDC provider, parse returned JSON to grab bearer token value, use said token value in header
curl -H "Authorization: Bearer ${token}"