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

141–150 of 290 posts

Re: Why is OAuth still hard in 2023?

#141

Post by p_l »

klabb3 wrote: post #110
p_l wrote: post #85

Earlier quoted context omitted.

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…

For service accounts, email is clearly not the right choice. I don’t have experience with enterprise auth, are Kerberos etc not using company email for human identity? > this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds For humans and especially end-users of consumer services, my observation is that the elaborate auth dances are using email ownership…

In case of OAuth2/OIDC, if I do not use external providers (like Google etc.), I can still deploy one of the many OAuth2/OIDC providers myself and centralise handling of user database this way.

This also means I have one place to support sending last resort emails

As for enterprise auth, a lot of places in fact do not use emails for identity. Sometimes there's more than one login id mapping to one identity (noticeable case - Kerberos/LDAP as done by Active Directory, where your login can come in email-style form and pre-AD form, and the email-style one doesn't have to correspond to an email)

Re: Why is OAuth still hard in 2023?

#142

Post by cryptonector »

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…

Except HTTP prohibits copying headers from redirect responses to redirected requests. That's why OIDC exists, to deal with that by abusing URI q-params.

I've an Internet-Draft somewhere to fix this by making it possible to indicate on a 3xx that this is for authentication (so copy Authorization: from redirect responses to redirected requests) and to allow 401s to have Location: headers that make it more like a 3xx, and 3xxs have WWW-Authenticate:, so you can negotiate between legacy HTTP auth and redirect-based authentication.

Re: Why is OAuth still hard in 2023?

#143

Post by dwaite »

idlewords wrote: post #78

I never understood how Oauth as a user experience is supposed to be distinguishable from phishing.

Many authentication systems push all phishing mitigation onto the user, e.g. "check the lock" (doesn't do anything) or "check the address bar" (not realistic for most users, ignores the ability to register official-looking DNS names).

So the answer is - OAuth doesn't solve the phishing issues around authentication any more than any other sort of non-curated hyperlink on the web.

WebAuthn, mutual TLS and Kerberos are the systems where that authentication is bound to a DNS domain or communications channel. Password managers also can provide this, although there are security considerations there such as competing web extensions, and it is a mechanism that the server cannot vet for risk analysis.

Such phishing-resistant mechanisms raise the bar for a successful attack from someone sending out a creative email to something a lot closer to coordinated/state-sponsored attacks on internet infrastructure.

Re: Why is OAuth still hard in 2023?

#144

Post by zmxz »

haswell wrote: post #115
zmxz wrote: post #82

Earlier quoted context omitted.

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

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…

> Forming an understanding of the basic concepts rarely happens in 10 minutes

It happens when you're working and have sufficient experience, knowledge and practice when it comes to web, programming and HTTP.

It's impractical, irresponsible and insane to have anyone other than a person with sufficient knowledge to work on application / API that supports OAuth and for person with proper expertise - the protocol is simple because it's literally the bare minimum needed to establish secure request/response pattern.

I work with SAML 2.0 and OAuth2/OIDC, I deal with programmers and other people within areas of API, authentication, authorization and it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. But, I did interact with several brilliant people with far less experience compared to me who did get the purpose of this protocol and who implemented it successfully and have done so quite fast.

What the wall of text means is that where there's will - there's a way. You can't force knowledge into audience who can't or refuse to understand it, so there's no point in even trying to do it let alone draw conclusions how the protocol is hard, confusing or difficult when there's whole knowledge void in other pre-requisite areas.

Re: Why is OAuth still hard in 2023?

#145

Post by madeofpalk »

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 to exchange refresh token for a new access token and refresh token

The tricky part is that a bunch is implementation specific, so memorising the above only gets you half way to implementing with another provider.

Re: Why is OAuth still hard in 2023?

#146

Post by neurostimulant »

TallGuyShort wrote: post #107
znpy wrote: post #96

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. Because it is, really. OAuth (2.0) is really the backbone for OpenID.

OpenID Connect, specifically, where a lot of people mix those up and start looking at using OAuth for authentication. And if I'm not mistaken, logging out is implementation-dependent in OpenID Connect. There's some pseudo-standards but implementations vary in my experience. And OpenID Connect also has multiple flows for different kinds of applications. There's still a lot of confusion and complexity here.

I'm still salty about how keycloak changed their openid logout behavior, removed the old behavior in the new version when there are still a lot of oidc clients out there that still expect the old behavior. I have two inatances of keycloak using the same version and somehow both have different iodc logout behaviors. I think it's due to one instance was upgraded from older version and inherited the old behavior, but I can't get the other instance to use the old behavior (the flag mentioned in the docs didn't work) unless I downgrade the version first.

Re: Why is OAuth still hard in 2023?

#147

Post by pas »

derefr wrote: post #120
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…

And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll take your email address and check the DNS record of the domain to figure out who your IdP is, and then send you there." Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all thos…

OIDC Discovery to the rescue!

https://swagger.io/docs/specification/authentication/openid-...

Re: Why is OAuth still hard in 2023?

#148

Post by magicalhippo »

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 both had to acquire and validate[1] tokens from Azure AD, both Client Credentials[2] and Authorization Code[3] flows, and found Microsofts documentation quite good. I've also had to acquire tokens using certificate-based Client Credentials flow from another party.

Overall I found it fairly OK, it's a bit of a learning curve when you're just used to basic user/pass, but it's fine.

However the main issue is that when it's not working it's very opaque. This is even worse when trying to _use_ the tokens.

I spent many hours trying to figure out why my Client Credentials tokens wouldn't work for logging on to Office365's IMAP server, only to spend half an hour searching and finding some Microsoft community forum post saying it wasn't implemented yet... they only supported Authorization Code flow. This has been fixed they say, I'll know later today cause that just came up as a priority ticket...

All you get back is some "nope", with no way to figure out why.

[1]: https://learn.microsoft.com/en-us/azure/active-directory/dev...

[2]: https://learn.microsoft.com/en-us/azure/active-directory/dev...

[3]: https://learn.microsoft.com/en-us/azure/active-directory/dev...

Re: Why is OAuth still hard in 2023?

#149

Post by klabb3 »

lmm wrote: post #131
klabb3 wrote: post #54

Earlier quoted context omitted.

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…

Email and SMS are inherently insecure, and it would be a lot harder for whoever's on the other end to apply security practices (e.g. look at where logins are coming from, rate-limit authorization attempts). They can't pass extra metadata back (user's name/address/avatar/etc.) and they can't do fine-grained permissions (grant me access to this github repo but not that one, grant me read but not write, ...). Plus I don…

> Email and SMS are inherently insecure

But nevertheless widely used as de-facto identity, I assume because account recovery in case of lost credentials is paramount. At least 90% of my accounts would be stolen or lost, today, should I lose access to my email.

I don’t particularly like email, for many reasons. Especially that most people’s email can be blocked by a faceless corporation that suddenly bans you. That said, I think there are far worse options, such as endless iterations on proprietary and ad-hoc auth “standards”. At least to me, the technical challenges of hardening email seem far less intimidating than educating the public on a new system.

> apps and smartcode verification are starting to be almost as secure and usable as the HTTPS client certificate support

I agree that client certs are greatly under-utilized and poorly supported by eg reverse proxies, but how would they help here? What’s the user flow for non-technical Joe to acquire a client cert to pay his bills?

Re: Why is OAuth still hard in 2023?

#150

Post by skissane »

jcranmer wrote: post #75
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…

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 had a token from OAuth server 1, and it needed to exchange it for a token from OAuth server 2, and we needed some policies to decide whether that token exchange was allowed or not. 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.

> Which ones are supported by the provider? You guessed it, it's all implementation-dependent.

Security needs vary widely from system to system. So they defined a protocol which supports many different scenarios. But if your application only needs two of them, why implement the other N? OTOH, for someone who actually needs one of those other scenarios, having it standardised makes their life easier. You can’t expect the protocol to tell you which scenario you have, that’s inherently “implementation-dependent”, to the point that calling it that is getting tautologous

Post reply on HN