What really grinds my gears about OAuth is when there’s 5 providers, plus an email signup, and I forgot which one I used last time. Then I end up creating a new account accidentally, sometimes with no way to retrieve the old one.
The simple solution is to do email signup in my opinion.
I don't want to be beholden to oauth providers for my account. A lot of services that provide OAuth signup/signin do it in a way that locks you out of the account if you can't use the OAuth provider anymore.
I don't remember exactly what happened but I initially created my Spotify account with an email, but then I became linked to my Facebook account, so my Spotify data (profile pic, name...) were pulled from my Facebook account.
And for a few years I wasn't able to break this link, so I was stuck with my Facebook account, even though I wanted to get rid of it.
Then one day, I was able to transform back my Spotify account to an email one, and I deleted my Facebook account.
I had several exchanges with Spotify support which where basically useless.
Basically it was something like, because I used the same email address for both accounts, they automatically made the link.
Now I always use email login and I used + aliases, not only to avoid that mess but obviously better track data leak/sellers.
PSA: you can often "upgrade" to email/password auth on sites that support it by doing a normal "forgot password" flow with the same email address as your OAuth account.
That is the beauty of password managers these days: I can manage a separate password for everything and it syncs to all my computers.
Plus by using a password manager I give the big players less ability to track me. (they still track me, but I'm not logged into them in the tab they are tracking which leaves some doubt for their algorithms)
If it is a business to business app, and your employer is paying for it, the employer typically want to use their own SAML or OIDC based login system.
It does depend on your user base too. If you are targeting devs, adding login with github is a good idea. For more mass market users, Facebook. If you are in China, you'd be fool not to offer login with WeChat. And so on.
I personally like having email as a backup option and always advocate making it available as a baseline.
I worked around this problem by adding an entry in my password manager with a username of "OAuth: Use Google" or something like that, so I'm informed when I habitually check my browser extension or when I attempt to auto-fill during login.
It's inelegant and could be better, but good enough.
Security breach: For a target with a Gmail account, create an account on an unsecured OAuth provider, login to such sites with the unsecured email, access their data because it allows auth with any OAuth provider.
On one hand I like that feature – on the other hand it somewhat terrifies me, since it essentially delegates email verification to any of their accepted OAuth providers, unless they make you re-authenticate using your existing credentials, or redo email verification, upon linking the accounts. And not nearly all sites do.
If you (the service you are signing up to) use a good auth solution it will prevent that and give you the option to merge the 2 identities (matching on the email address)
sadly most don’t care about how bad their authN is which is mind boggling to me but reality
An evildoer hacks into my e-mail account, michaelt@example.com, creates a salesforce.com account (with a password). They delete all the e-mails about account creation.
I discover the hack and change the passwords on every account I know about - but I don't know about the salesforce account (in fact I don't have the password to it) so the hacker retains access.
Should the hacker be able to visit gitlab.com, hit the log-in-with-salesforce button, and get access to the michaelt@example.com account?
I've encountered a Matrix server/Element client that doesn't always present the same options for providers, making it very difficult to log in on a second machine.
>What really grinds my gears about OAuth is when there’s 5 providers, plus an email signup, and I forgot which one I used last time.
Yeah there are a couple of sites where I do the login with google, but most of the time I go through the steps of making a real account specifically because of this issue. There should be a way to tell if you already have an oauth account without it just making you a new account if you choose the wrong method.
I worked on a system that implemented OAuth against maybe a half-dozen APIs. None of them were the same. It's a series of rough guidelines, a pattern, not a spec.
The extra annoying part is that learning each auth is basically a single-use exercise. Sure, you get better from 0-5 but from 5-100 it's mostly just grumbling and then trying to forget whatever esoteric "standard" was implemented.
Source- done over 300 system connections. Save the straight API keys, they're all special and unique snowflakes.
See also: EDI / EDIFACT / ANSI X12.
It was supposed to standardize the way businesses exchange data, but every company implements it differently so integrations take forever, and there's an entire of middlemen offering solutions to make it faster.
It was an intranet with an OAuth server for a company. A team that implemented an OAuth login for another related app wouldn't follow the official specs. They've asked for me to change how OAuth works because otherwise it would be "impossible" for them to implement the login, and what they were asking were seemingly random changes that didn't follow any official specs. After a couple of months of back and forth and no matter what I said, the conclusion that everyone else at the company agreed is that I was being uncooperative.
In the end, I caved in, and there's now an OAuth Frankenstein just for them that lives alongside the OAuth for everyone else. I've made a dedicated #special-needs section just for them in the docs, with no explanations why, and I hope other teams will enjoy the read.
I'd like to add that so many providers do not support either `prompt=select_account` or just natively ask the user which account to login to, mainly for OIDC. Working with IAM systems at work and using different test accounts, it's frustrating when you can't easily log out of the destination IdP for, say, SSO.
My experience with `prompt=login` is also mixed. Okta's behavior does not indicate which account you're logging into (no username/email address), and only asks to re-input your password. They have a "Back to sign in" link button, but that loses all OAuth context and does not lead you back into the app you're attempting to OAuth into, unless if you specifically override that button to hit Okta's logout endpoint and with a redirect back to your OAuth authorize endpoint/session.
It's janky. And I would know because we had to implement that at work.
I only dabbled with OpenID as an end-user, but I really really liked the fact that I could tie my identity to a domain I owned, and then temporarily delegate the credential-mechanics to another entity.
In this way, the identity was durable and portable, at least as long as one maintains control over the URL.
Some of these problems (esp. Facebook's) look like someone used an existing service framework to code OAuth2, and either didn't or couldn't adjust the framework to conform to spec.
Some of the other problems look like a common problem with scripting—the ease of treating an int like a string, and vice-versa.
"This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision."
May not be a thought process, just a rush to get the service into production, and a lack of attention to detail. Lots of coders treat error-handling as a hassle or optional, hence the 80-20 rule.
> This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision. And also please fix it.
Using php or something and not paying attention? Read the value from database, by default php casts all colum types to string in retrieval, except for a null value, or if you tell it to try to match column types to php types.
"I had a “Dear AWS” section since I’ve received multiple bug reports on it when used with my OAuth client library. However, I couldn’t recreate any of the reported issues so I have removed it from the post."
I wish the section would have been kept. I don't care about AWS but I think this article is an excellent checklist for common pitfalls. So keeping them, even if one provider has fixed them would still be useful.
One big issue with AWS OIDC is that API Gateway uses the id_token to validate requests, not the access_token as the spec requires. Unless you're doing subscriptions through AppSync, then it does require the access_token, not the id_token. But their own amplify library doesn't realize this, so you have to trick it. Fun stuff to implement on the front end.
Readit News
I don't want to be beholden to oauth providers for my account. A lot of services that provide OAuth signup/signin do it in a way that locks you out of the account if you can't use the OAuth provider anymore.
I had several exchanges with Spotify support which where basically useless. Basically it was something like, because I used the same email address for both accounts, they automatically made the link.
Now I always use email login and I used + aliases, not only to avoid that mess but obviously better track data leak/sellers.
Plus by using a password manager I give the big players less ability to track me. (they still track me, but I'm not logged into them in the tab they are tracking which leaves some doubt for their algorithms)
> I don't want to be beholden to oauth providers for my account.
And which email provider are you using? You rely on them too, right? If you use a free email provider like Gmail or others, you are relying on them.
Personally I'm a big fan of letting someone log in any which way they want.
OAuth (or federated login if we're being precise) decreases friction.
Here's a link from Auth0 which references some other links talking about double digit increases in conversions when social login is available: https://auth0.com/blog/how-to-use-social-login-to-drive-your...
If it is a business to business app, and your employer is paying for it, the employer typically want to use their own SAML or OIDC based login system.
It does depend on your user base too. If you are targeting devs, adding login with github is a good idea. For more mass market users, Facebook. If you are in China, you'd be fool not to offer login with WeChat. And so on.
I personally like having email as a backup option and always advocate making it available as a baseline.
It's inelegant and could be better, but good enough.
sadly most don’t care about how bad their authN is which is mind boggling to me but reality
Imagine the following scenario:
An evildoer hacks into my e-mail account, michaelt@example.com, creates a salesforce.com account (with a password). They delete all the e-mails about account creation.
I discover the hack and change the passwords on every account I know about - but I don't know about the salesforce account (in fact I don't have the password to it) so the hacker retains access.
Should the hacker be able to visit gitlab.com, hit the log-in-with-salesforce button, and get access to the michaelt@example.com account?
The email address you get from an oauth provider should never be trusted.
Try visiting this URL twice, but use two different login methods (that use the same address).
https://auth.ai.moda/pages/v1.0.0/login
Yeah there are a couple of sites where I do the login with google, but most of the time I go through the steps of making a real account specifically because of this issue. There should be a way to tell if you already have an oauth account without it just making you a new account if you choose the wrong method.
Our experience was exactly like OP describes: https://www.nango.dev/blog/why-is-oauth-still-hard
Source- done over 300 system connections. Save the straight API keys, they're all special and unique snowflakes.
“… one of the principle issues is that it's less a protocol and more a skeleton of a protocol.”
https://news.ycombinator.com/item?id=35720336
It was an intranet with an OAuth server for a company. A team that implemented an OAuth login for another related app wouldn't follow the official specs. They've asked for me to change how OAuth works because otherwise it would be "impossible" for them to implement the login, and what they were asking were seemingly random changes that didn't follow any official specs. After a couple of months of back and forth and no matter what I said, the conclusion that everyone else at the company agreed is that I was being uncooperative.
In the end, I caved in, and there's now an OAuth Frankenstein just for them that lives alongside the OAuth for everyone else. I've made a dedicated #special-needs section just for them in the docs, with no explanations why, and I hope other teams will enjoy the read.
We're still shaking out bugs and bad behaviors after adding multi account on GitHub, I get why folks might not want to implement it.
It's janky. And I would know because we had to implement that at work.
Sure there's the spec, but it's a lot to keep track of for the intern that inevitably ends up implementing such things.
Having a test suite you to verify you didn't mess up would be very useful.
In this way, the identity was durable and portable, at least as long as one maintains control over the URL.
Some of the other problems look like a common problem with scripting—the ease of treating an int like a string, and vice-versa.
"This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision."
May not be a thought process, just a rush to get the service into production, and a lack of attention to detail. Lots of coders treat error-handling as a hassle or optional, hence the 80-20 rule.
Using php or something and not paying attention? Read the value from database, by default php casts all colum types to string in retrieval, except for a null value, or if you tell it to try to match column types to php types.
Deleted Comment
I wish the section would have been kept. I don't care about AWS but I think this article is an excellent checklist for common pitfalls. So keeping them, even if one provider has fixed them would still be useful.