Why is OAuth still hard in 2023? • Hacker News Board

Re: Why is OAuth still hard in 2023?

#271

Post by 0x457 » Thu, Apr 27, 2023, 5:41 PM UTC

paulddraper wrote: post #264

0x457 wrote: post #88

Earlier quoted context omitted.

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.

That just pushes the problem around, yes? So now the client servers have store/check the lifetime of tokens rather than resource servers. Does that actually improve OAuth as a whole?

Even without refresh tokens, clients need to check lifetime. If the token is opaque and the lifetime is unknown, it is no different from a session cookie.

> Does that actually improve OAuth as a whole?

Like I said, this is an improvement for whoever is validating tokens and only them. Refresh tokens are not hard to use, not sure what's the confusion here:

`token = token.is_expired ? refresh_token() : token`

That's all. Even in wordy rust, it doesn't take much:

https://docs.rs/yup-oauth2/6.5.1/src/yup_oauth2/authenticato...

Are you mad that, unlike with opaque token, you know ahead of time when it's expired for sure rather than when you got 401?

Re: Why is OAuth still hard in 2023?

#272

Post by snapetom » Thu, Apr 27, 2023, 5:49 PM UTC

izacus wrote: post #94

thepasswordis wrote: post #61

Because 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…

That drove me up the wall in Python so much - ALL the documentation just described how to put a massive library into a cookie cutter example and never explained how it's supposed to work so I could debug the darn thing.

Not sure if they still do this, but when I first started learning, front and center of the documentation was telling you how to do it in a mobile app, then JS SPA app. The use case of a backend API+JS/mobile frontend was buried. And it was all stupidly named. It wasn't blatant like 1) MOBILE APP FRONTEND 2) JS APP FRONTEND 3) API BACKEND + FRONTEND.

So for me, mobile wasn't relevant, SPA wasn't relevant, and my use case, the third one was hard to find.

Re: Why is OAuth still hard in 2023?

#273

Post by btilly » Thu, Apr 27, 2023, 5:52 PM UTC

pcthrowaway wrote: post #229

btilly wrote: post #26

Earlier quoted context omitted.

I have read many docs. The one that I find easiest to understanding is still the one that I wrote about a decade ago when I first had to work with OAuth 2. All others I understanding by mapping what they said to concepts in mine, and that seems to work pretty well. My document is available at https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut... . Even though you're unlikely to ever use that library or lang…

This is the first Oauth document I've seen with a no-nonsense "Terminology" section. Thank you! The only thing I'd suggest is putting the terminology first, so readers can first correct their misconceptions from all the terrible literature around this.

I thought about it, and settled on the compromise of referring to it up front, and then putting it at the end.

That's because there are many ways you could use a document like that. And the Terminology section is very overwhelming unless your goal is to understand how OAuth 2 REALLY works, and why it works that way.

Re: Why is OAuth still hard in 2023?

#274

Post by snapetom » Thu, Apr 27, 2023, 5:52 PM UTC

remus wrote: post #12

It'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…

And each provider you intend to support exponentially clutters up code in the frontend and your /authenticate endpoint in the backend. Imports for each one, IF/ELSE statements to handle each one.

Re: Why is OAuth still hard in 2023?

#275

Post by ssd532 » Thu, Apr 27, 2023, 6:21 PM UTC

xyst wrote: post #189

Personally, I have transitioned away from these third party IdPs. I have turned to spinning up my own authentication and authorization stack using an open source ecosystem like "Ory". With just a single helmfile, I can deploy the entire application stack on my local machine (authN, authZ, smtp server,app db, application). Gives me ease that I don't have to rely on a third party vendor just for testing simple app flow…

If you have already evaluated what are your thoughts on Keycloak? How does it compare with your stack?

Re: Why is OAuth still hard in 2023?

#276

Post by glonq » Thu, Apr 27, 2023, 6:22 PM UTC

My current project is the first where we decided to use "real proper" authN/authZ instead of a home-brew solution or a minimal solution like asp.net simple auth.

I found that all the off-the-shelf solutions were either easy but expensive or cheap/free but difficult. I failed to find that mythical cheap or free and also easy and fabulous. Eventually we settled on self-hosted KeyCloak as the best bang for the buck. It took a bit of effort to get there, but we are happy with the results.

Re: Why is OAuth still hard in 2023?

#277

Post by p_l » Thu, Apr 27, 2023, 7:21 PM UTC

cryptonector wrote: post #266

p_l wrote: post #239

Earlier quoted context omitted.

Oh boy, Negotiate. The wonderful system that works easily only on Windows. I love it though, I use it as part of OIDC flows, because then I don't need to directly implement it for every application, I just make them call to Keycloak for it.

It works on Unix, what are you talking about.

The most painful part of getting Kerberos logins working on web apps in one of my jobs was getting Firefox to accept Negotiate headers from our domains and actually perform GSSAPI exchange using users keytab.

Windows has it somewhat centralized and well supported across many applications (especially those that simply use system-provided HTML widget), and at least Chrome automatically picks up system-wide config.

Re: Why is OAuth still hard in 2023?

#278

Post by webhamster » Thu, Apr 27, 2023, 7:29 PM UTC

paulddraper wrote: post #268

webhamster wrote: post #228

Earlier quoted context omitted.

That's not correct. There are a number of attacks that can be mitigated by both, but PKCE serves as a very effective defense in case an authorization code leaks to an attacker. Such a leak can be caused by a malicious script on the redirect URI, referer headers, system or firewall logs, mix-up attacks and other problems even when the redirect URIs are restricted. There is a good reason why we mandate both redirect UR…

Your comment doesn't explain what attack can be mitigated by redirect allowlist but not PKCE.

For starters, without restrictions on the redirect URI, I (as the attacker) can just redirect a user to the authorization endpoint with a client ID of a trustworthy client, a redirect URI pointing to my server, and a PKCE challenge that I selected so that I know the PKCE verifier. The auth code will end up at my server and I can redeem it, giving me (instead of the trustworthy client) access to the user's resources. If the client is a confidential client, I can use a authorization code injection attack to redeem the code and work with the user's resource.

Re: Why is OAuth still hard in 2023?

#279

Post by ksm » Thu, Apr 27, 2023, 7:52 PM UTC

elevation wrote: post #263

madeofpalk wrote: post #145

Earlier quoted context omitted.

I've reimplemented oauth for the same provider (bungie.net) countless times. I think it might seem daunting, but when you break it down into the steps it's pretty simple: - Send user to example.com - Eventually they're sent back to yoursite.com with a ?code=abc - Call example.com/OAuth to exchange ?code=abc for access token and refresh token - You're done (for now) - When access token expires, call example.com/OAuth…

I have an application with this flow already implemented to authenticate a user. But the application currently has it's own authorization policy in a flat file which organizes users into groups and gives groups permission to take certain actions, a simple RBAC. I'd like to refactor this so that the authorization is delegated to the OAuth server. Ideally I want to be able to ask a keycloak/okta server "now that user X…

I had bit similar need when implementing our own OAuth2 authorization server to be used by our own (three) web applications and several APIs related to them, all of which use the same backend to store users and API keys with differing permissions to logical entities our datamodel consists of. These permissions are somewhat naturally mapped to scopes, but the main issue is that single user or API key could have differing permission across multiple logical entities, so it's M-to-N representation (M logical entities, with N different scopes). So simple returned scopes would not suffice, as resource server needs to know which entity or entities the caller also has access to, according to scopes.

As I could not find any pre-existing good guidance on solving this, I ended up implementing it by having the resource servers (i.e. APIs) check the token using token introspection endpoint at the auth server (not the RFC version of introspection, just private one for now but I may add the RFC compliant version as well so it could be called by 3rd parties as we have not yet rolled out this OAuth2 based setup for our customers). Part of that return information from the introspection endpoint is this permission mapping between logical entities and scopes, so the resource server can know to which entities caller has which scopes. Of course, as our access tokens are not JWT and just opaque (encrypted) data, the introspection endpoint then need to decrypt it - just so it can quickly validate expiration etc. - and if valid, fetch a matching copy from the database that has more contextual information than what's encoded inside the client-supplied access token. Otherwise, the length would be prohibitive if token would be fully self-contained with these extra information.

Maybe this same kind of method could be used for your use case as well, encoding authorization policy adjacent to the access token in your backend, and looked up by app using it after it has received the token?

Re: Why is OAuth still hard in 2023?

#280

Post by cryptonector » Thu, Apr 27, 2023, 8:07 PM UTC

p_l wrote: post #277

cryptonector wrote: post #266

Earlier quoted context omitted.

It works on Unix, what are you talking about.

The most painful part of getting Kerberos logins working on web apps in one of my jobs was getting Firefox to accept Negotiate headers from our domains and actually perform GSSAPI exchange using users keytab. Windows has it somewhat centralized and well supported across many applications (especially those that simply use system-provided HTML widget), and at least Chrome automatically picks up system-wide config.

Just use a reverse proxy. Envoy, Nginx, whatever.