Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is OAuth still hard in 2023?

nango.dev

Post reply on HN
Print view View original

161–170 of 290 posts

Re: Why is OAuth still hard in 2023?

#161

Post by sytringy05 »

asdfman123 wrote: post #157
znpy wrote: post #98

Earlier quoted context omitted.

when it comes to this kind of things there's really no way around it: you're supposed to read the RFCs: - https://www.rfc-editor.org/rfc/rfc6749.html : The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6750.html : The OAuth 2.0 Authorization Framework: Bearer Token Usage

As someone who is hired to sling out features as rapidly as possible, that’s not going to happen. I mean, you might say “but you should” or “it would actually help” or “in an ideal world…” but it is still, realistically, not going to happen.

Well hopefully someone has taken the time to, or there will be nasty surprises

I certainly don't want people building security sensitive parts of an app to be slinging the features out.

Re: Why is OAuth still hard in 2023?

#162

Post by 0xbkt »

Tangentially related: what do you use today to make authn/z work for your web sites/applications where you only do first party login (i.e. you don't do social login etc.)? Create a `users` table in your database and implement the logic on your own? Or proxy to stuff like Ory Kratos and act as a translation layer through a network call?

Re: Why is OAuth still hard in 2023?

#163

Post by LukeShu »

skissane wrote: post #150
jcranmer wrote: post #75

Earlier quoted context omitted.

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth, and you realize that basically everything is implementation-dependent. You somehow register with the provider as a client (out of band and completely implementation-dependent). Then you ask them to log you in by sending a request to an implementation-dependen…

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which ha…

> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol

> OAuth supports lots of different scenarios.

But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed):

- OAuth: implementation defined

- most implementations: use our library, which validates the token using undocumented logic

- OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips

- RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time.

So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same.

(In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)

Re: Why is OAuth still hard in 2023?

#164

Post by TobyTheDog123 »

No one implements it the same way.

Some require scopes, some don't.

Some require comma-separated scopes, some want an array.

Some require an HMAC signature, some don't.

Some want a JSON body, some want a urlencoded form.

Etc.

Etc.

Etc.

You're never implementing OAuth, you're implementing some company's bastardized flavor.

Re: Why is OAuth still hard in 2023?

#165

Post by chasd00 »

madeofpalk wrote: post #145
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…

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…

Yeah I don’t see what the big deal is. You don’t need to know every oauth flow by heart and most of the time you’re going to be using the authorization code flow anyway. There are tons of articles and comments on HN about much more complex things than oauth every day.

Re: Why is OAuth still hard in 2023?

#166

Post by haswell »

dwaite wrote: post #136
haswell wrote: post #115

Earlier quoted context omitted.

For what it’s worth, I taught a series of classes/labs intended to help developers within my former employer’s ecosystem understand OAuth. What I learned after delivering the content to hundreds of devs over the years: OAuth confuses people, and for completely understandable reasons. Most people think about auth in terms of usernames/passwords or API keys. The mental models associated with these do not transfer to OA…

> Most people think about auth in terms of usernames/passwords or API keys. OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication. But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.

Yeah, this misconception is at the heart of so much confusion, and far too many OAuth implementations were clearly borne of "well, the customer was demanding we support OAuth so we implemented it", and there was clearly no understanding of the distinction between authn and authz, or what use cases are actually getting solved.

I once worked with a vendor who provided an API and required all API clients to use OAuth with Auth Code Grant Flow. The API was designed to support backend automation use cases within the product, and could execute functionality behind the scenes headlessly. Auth Code Grant Flow requires interactive login by a user sitting at a keyboard, and they never stopped to consider that backend automation use cases are not going to work well if someone has to periodically execute an interactive auth flow. This wasn't a once-in-a-year occurrence since they enforced relatively short refresh token timeouts.

The degree of confusion and the prevalence of that confusion on this subject is quite high. Someone gets a task to "Implement OAuth", and they see that Auth Code Grant Flow is the most common, so that must be what we should implement.

Re: Why is OAuth still hard in 2023?

#167

Post by chasd00 »

missingdays wrote: post #50
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…

OAuth specification was the best source for me. All provider docs are simplified and usually specific to the provider

It’s been a while since I’ve read the RFCs but I recall them being very accessible and clearly written.

Re: Why is OAuth still hard in 2023?

#168

Post by fordsmith »

lukev wrote: post #137

Given that this seems to describe a real problem, why hasn't anyone launched a proxy service that normalizes across the varying implementations? Why should tens of thousands of developers have to discover the particular quirks of an implementation instead of doing it once and re-using the results?

They have. https://clerk.com/ is an example that I have been looking to use lately

Re: Why is OAuth still hard in 2023?

#169

Post by cogman10 »

skissane wrote: post #150
jcranmer wrote: post #75

Earlier quoted context omitted.

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth, and you realize that basically everything is implementation-dependent. You somehow register with the provider as a client (out of band and completely implementation-dependent). Then you ask them to log you in by sending a request to an implementation-dependen…

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which ha…

> And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that.

That's because OAuth in the industry has been changed to only talk about authentication (AuthN) and not (or very lightly) authorization (AuthZ).

And, for the better, AuthZ is so use-case specific that bundling it together with AuthN is just asking for trouble.

Consider AWS and IAM permissions. How would you implement an IAM AuthZ policy system with OAuth? Would you actually want to?

AuthN is a relatively simple process which is why that flow through OAuth (and specifically OIDC) is fairly well trodden and defined. The OAuth Authz capabilities are infrequently used which is why you see them being so spotty.

Re: Why is OAuth still hard in 2023?

#170

Post by uriah »

rad_gruchalski wrote: post #109
radlad wrote: post #104

Earlier quoted context omitted.

Yes, but checking refresh tokens will occur much less frequently than checking access tokens. So you can imagine, for example, access tokens being JWT, so they are cheap to check. But every so often you have to validate the refresh token against MySQL (or BigQuery or what-have-you), which is more expensive.

That's all clear to me. But technically there exists a method to revoke an issued token. It's just that long lived tokens mean potentially lots of them == increased storage cost. It would be pretty silly not to check for revocation. How would one implement logout otherwise? Relying on just clearing session cookies? What if I obtained those cookies using something else than a browser and I can hold on to the cookie ja…

Login state for the identity provider and for the client application are different. Cookies are a reasonable way to implement it. Cookies + session storage backend will allow you delete sessions on the server side if you are worried about users keeping themselves logged in (?).

Your app is also responsible for deciding who has access. The identity provider is just handling the “is this person who they say they are” part.

Checking for revocation is checking whether the IdP still thinks that token identifies the user correctly. I don’t think it’s universally true or desirable that refresh tokens get revoked on logout. I don’t necessarily want logging out of Gmail to log out of Spotify just because I used Google auth for both.

Post reply on HN