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

221–230 of 290 posts

Re: Why is OAuth still hard in 2023?

#221

Post by LukeShu »

krinchan wrote: post #207
LukeShu wrote: post #198

Earlier quoted context omitted.

> In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon…

...what? The server generates the auth code and redirects the user agent to your callback. You exchange that code with the IDP (over HTTPS which yeah that's its own nest of wormy trust) to get back a token. They can't inject a token because you don't get the token from them, just the one time code. If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS…

My apologies, it's been a while and I was forgetting about the authorization-code exchange step. So yes, for the most part "client"s can treat the bearer token as opaque. But "resource server"s absolutely cannot.

> If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint.

If it's a JWT, which it doesn't have to be. OIDC allows the token to either be an RFC 6750 opaque token, or an RFC 7523 JWT, and overwhelmingly implementations use a "bearer" (6750) token. But, most of the time it's a JWT, so as I said, closing your eyes and pretending it's a 7523 token works, and so then you can just pull the keys from the JWKS endpoint.

> Introspection is standardized and an RFC.

In my experience, it is exceedingly rare for an IDP to implement RFC 7662 token introspection

> All these URLs are defined and provided via the .well-known/openid-configuration endpoint.

Yeah, OIDC-discovery is pretty sweet. And if the IDP implements OIDC-discovery, then it probably implements OIDC-core, or at least enough of it that you can use the user-info endpoint, like I mentioned. But I've seen IDPs that don't.

Have you ever used OAuth2 outside of OIDC?

Re: Why is OAuth still hard in 2023?

#222

Post by vbezhenar »

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…

Well, my experience is like install keycloak, configure some framework plugin (like Spring Security) and that's about it...

I have rough understanding of oauth but never had to dive in.

Re: Why is OAuth still hard in 2023?

#223

Post by LukeShu »

rtpg wrote: post #211
krinchan wrote: post #207

Earlier quoted context omitted.

...what? The server generates the auth code and redirects the user agent to your callback. You exchange that code with the IDP (over HTTPS which yeah that's its own nest of wormy trust) to get back a token. They can't inject a token because you don't get the token from them, just the one time code. If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS…

Oh, thank you for reminding me of the well-known endpoint, was having trouble finding it in the OAuth RFCs but I wonder if it's pulled in elsewhere. > They can't inject a token because you don't get the token from them, just the one time code. that's not correct in the most common flow? The most common flow involves the user agent providing the information via a GET, so they can theoretically provide a token. The rea…

.well-known/openid-configuration is specified as part of OpenID Connect (OIDC) Discovery[1]. OIDC is separate from and on-top-of OAuth2. The OIDC specs come through the OpenID Foundation, not through the IETF (so not RFCs). (Also, while what they specify is super useful, they aren't nearly as well written as RFCs tend to be :) )

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html

> that's not correct in the most common flow?

No, he's right, I was misremembering (assuming "the most common" flow is the "authorization code" flow specified in RFC 6749 §4.1). The user-agent provides a one-time "authorization code" to the client via a GET, and then the client receives that "authorization code" and does its own POST to the IDP to exchange that "authorization code" for the final "access token".

Re: Why is OAuth still hard in 2023?

#224

Post by rtpg »

krinchan wrote: post #214
rtpg wrote: post #211

Earlier quoted context omitted.

Oh, thank you for reminding me of the well-known endpoint, was having trouble finding it in the OAuth RFCs but I wonder if it's pulled in elsewhere. > They can't inject a token because you don't get the token from them, just the one time code. that's not correct in the most common flow? The most common flow involves the user agent providing the information via a GET, so they can theoretically provide a token. The rea…

That's something that isn't OAuth2 or your end point is accepting something insane. Are you talking about the PKCE variant of authorization code flow which is what replaces implicit flows in native apps and SPAs? Because those use code_challenge and code_verifier fields, not the state field. If you're doing all that in the state field with signed nonces you really should move to PKCE.

Using [0] as a reference, I'm talking about Step 3. This is, in my experience, the "normal" way that people are setting up OAuth between 2 services, with a user going through the flow.

[1] includes info on this (see "flawed CSRF protection")

[0]: https://www.digitalocean.com/community/tutorials/an-introduc...

[1] https://portswigger.net/web-security/oauth

Re: Why is OAuth still hard in 2023?

#225

Post by rtpg »

LukeShu wrote: post #223
rtpg wrote: post #211

Earlier quoted context omitted.

Oh, thank you for reminding me of the well-known endpoint, was having trouble finding it in the OAuth RFCs but I wonder if it's pulled in elsewhere. > They can't inject a token because you don't get the token from them, just the one time code. that's not correct in the most common flow? The most common flow involves the user agent providing the information via a GET, so they can theoretically provide a token. The rea…

.well-known/openid-configuration is specified as part of OpenID Connect (OIDC) Discovery[1]. OIDC is separate from and on-top-of OAuth2. The OIDC specs come through the OpenID Foundation, not through the IETF (so not RFCs). (Also, while what they specify is super useful, they aren't nearly as well written as RFCs tend to be :) ) [1]: https://openid.net/specs/openid-connect-discovery-1_0.html > that's not correct in t…

This is me misusing the word "token". Access tokens are gotten via POST, but the one-time code is gotten via GET and, absent usage of things like the state parameter, can easily lead to malicious attacks.

Re: Why is OAuth still hard in 2023?

#226

Post by LukeShu »

krinchan wrote: post #214
rtpg wrote: post #211

Earlier quoted context omitted.

Oh, thank you for reminding me of the well-known endpoint, was having trouble finding it in the OAuth RFCs but I wonder if it's pulled in elsewhere. > They can't inject a token because you don't get the token from them, just the one time code. that's not correct in the most common flow? The most common flow involves the user agent providing the information via a GET, so they can theoretically provide a token. The rea…

That's something that isn't OAuth2 or your end point is accepting something insane. Are you talking about the PKCE variant of authorization code flow which is what replaces implicit flows in native apps and SPAs? Because those use code_challenge and code_verifier fields, not the state field. If you're doing all that in the state field with signed nonces you really should move to PKCE.

It's to prevent CSRF attacks. The attacker writes their own client and does half of a login on their own end (getting an authorization-code, but not yet exchanging it for an access-token), and then tricks the end-user to navigate to //service/connect-slack-finalize?code=&state=. But with the state parameter, the client can check the state parameter against a session cookie that it set previously, and say "wait a minute, this is the conclusion of a login from a different browser". Depending on what all session-state the client is keeping track of, it may make sense to sign that state-parameter-nonce to avoid having to remember session state server-side; but the simple case would be to just check whether it == a cookie value.

Re: Why is OAuth still hard in 2023?

#227

Post by domrdy »

sho wrote: post #206
domrdy wrote: post #180

I've been using WorkOS for my SaaS products and I'm pretty satisfied with it. It's straightforward to set up Google/Microsoft/MagicLink (free), including staging and production environments. The best part, though, is that it lets my enterprise customers configure their own SAML/OpenID Connect IDPs. I get charged per connection, so I just pass that cost onto my customers. As a solo developer, I'd have a hard time supp…

Their product looks great but the price seems insane. $125/m per connection? That's very hard to swallow for a SAAS looking to charge maybe $10-30 per seat. I get it, "enterprise!", but that's a pretty high barrier to entry for a company still establishing itself.

Absolutely, it's not the most inexpensive option out there. My strategy is, that I only initiate a connection once an agreement with an enterprise client is officially signed. This way, I'm not investing upfront without the assurance of a paying customer. I find this approach works quite well for my situation.

Re: Why is OAuth still hard in 2023?

#228

Post by webhamster »

paulddraper wrote: post #9

Example: What is the purpose of OAuth having specifications for redirect URI allowlist AND PKCE? None. They are entirely duplicative features. But ... reason, reason, reason ... they both exist, and are going to exist, forever. EDIT: I should say, PKCE is a functional superset of redirect URI allowlist.

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 URI allowlisting AND PKCE in the OAuth Security BCP RFC draft. One learning from our discovery of mix-up attacks with "code injection" was that client authentication is not sufficient to prevent the misuse of authorization codes.

Re: Why is OAuth still hard in 2023?

#229

Post by pcthrowaway »

btilly wrote: post #26
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 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.

Re: Why is OAuth still hard in 2023?

#230

Post by pcthrowaway »

jkubicek wrote: post #105
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…

Your documentation is amongst the best I've seen on OAuth, but it suffers from the same naming confusion I always run into when I'm reading OAuth docs. > OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers If I'm trying to write a Mastodon client, I'm reading this line piece by piece: > OAuth 2 makes it easy for large service providers "service…

Read the introduction again, and then follow the link to the Terminology section.
Post reply on HN