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.
Sometimes. It depends on how they bind your account. On the projects I’ve worked on, we’d always “upgrade” but I’ve seen plenty of sites that just create a new account. A behavior I find very annoying.
I have noticed a trend in many sites to reduce the number of social signin options down to maybe google (for android) and apple (for iOS) plus email / password. I suspect the “which signin method did I use” is one of the main reasons. That and clutter reduction.
By the way one of the big reasons a site might push you toward social signin is because those accounts are usually already verified. When you run through your own email / password flow you need to verify the email yourself (if that is important to your product). It’s an extra step that doesn’t need to happen when you click the magic google / apple button.
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.
> And which email provider are you using? You rely on them too, right?
Not really, as I use my own domain so can just move that between providers. Exactly because I also don't want to be beholden to a free mail provider either.
> Personally I'm a big fan of letting someone log in any which way they want.
Sure, if people do want to use oauth by all means the should. I just don't think the short term signup convenience outweighs the longer term stuff like:
- annoyances of remembering how you signed up, the initial context I replied to.
- Having a extra service mixed in
- The privacy implications of your oauth provider having a neat list of the services you use.
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.
If you use a password manager (and my condolences to those who don't), there's really no benefit to using OAuth over an email sign up. It can prepopulate your personal information, but I usually don't want that for the services I sign up for.
There's a couple of services where I prefer to use github for sso because I need them to integrate with data stored there, and it makes sense to me to "bundle" those accounts. But that's very much an edge case.
Is this where I complain about companies that insist I install their MFA app rather than just letting me use Google Authenticator? You're not special.
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.
Easily preventable. Ask the user to supply a credential before linking the accounts or only allow account linking if the email is verified at the idp (as someone else noted this is not possible for all idps but for google it is)
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?
If the attacker has hacked your email then they could presumably do a reset flow on gitlab and reset the password and clear any evidence. The identity provider step is unnecessary. If we assume that linking the salesforce account to gitlab generates an email. Then unless the attacker has persistent access to the email account you’d know about it. If they have persistent access then the existence of the linked account doesn’t matter. They can just do password resets whenever. This does assume linking an account generates an email. MFA or forced authentication with existing account to link a new identity provider makes sense. But in terms of password reset a hacked email is pretty much the keys to the kingdom anyway.
I suppose the slight difference is that with the password reset flow you’d know that you couldn’t login. But nine times out of ten I’d imagine you’d just do your own password reset upon finding you couldn’t login.
I agree sibling comments are not quite correct about persistent email access. You could fix the email problem while the "backdoor" to Gitlab remains.
The problem statement says this about corrective action:
>I discover the hack and change the passwords on every account I know about
In actuality, the corrective action is to change the passwords and revoke any SSO integrations.
To the original point, this does add more overhead to the process, probably isn't obvious to most people, and depends on the site having clear UI for the topic.
Mostly but not entirely true. If Google oauth gives you an @gmail.com email, you can trust it.
A more accurate formulation would be: the email address you get from an oauth provide must not be trusted unless the oauth provider controls the email domain and guarantees no re-use of addresses.
Not that it’s practical to special case every such provider, but with Gmail handling 25% of email, there can be good UX affordances for them a few others.
Even in the case of gmail, which is the best case, you can not be sure the person in control of the Google account is the same as the one that used that gmail address to create an account on your site. The person might have got their Google account hacked, they might have used a shared gmail account to sign up, your service might not have been properly verifying email addresses when they signed up, etc.
But yes, to be fair, if you have email-based password reset functionality, it is not really an additional security vulnerability.
Control of the Gmail account and ability to get an oath token for that account are one at the same, as far as I know. Both indicate you’ve authenticated as that user with Google.
There are a few others. I’m not sure it’s worth the special casing, but it can be a better user experience.
'Never' is a bit strong. It depends a lot on what you're using the email address for. And it's probably safe to trust gmail addresses coming from google, for instance.
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.
I've read the RFCs several years back and they did not feel clearly written, not like a protocol spec. Maybe it was just me. The reality is each OAuth implementation is unique. Almost no two are the same.
All the problems mentioned in the blog post are due to the providers not following what the spec clearly said.
If you have an example of where that's not the case, I would also love to hear as I work in this area (perhaps you're thinking about how OAuth does not specify at all how authentication happen? But that was a good call, OAuth 1 did and it was too limiting... also OpenID Connect is pretty widely adopted now, and it fills that gap well).
What that tells me is that people who cannot read and understand a specification (or willingly ignore what the spec says) are implementing it anyway. I claim the spec is completely clear on all the points raised in the blog post. You can't just handwave that away without specifically telling what point was unclear.
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.
Emergency reserve military duty, a sudden sickness, email delivery issues, or even a temporary financial problem at the wrong time of year could all be reasons to missing the domain renewal window. It's happened to people far smarter than me.
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.
This allows clients to interop with any server. Doing the shit Facebook is doing completely ignores one of the main objectives of implementing a RFC: interoperability.
Dear OIDC/OAuth Providers, please do proper support for SCIM, design your systems with "API first mindset" and let me design my routes for redirects and embedded login functionality ... before you move onto GNAP (Grant Negotiation and Authorization Protocol) https://oauth.net/gnap/ ... reconsider your decisions
OAuth is such a bad standard, if you even want to call a loosely cross-referenced bundle of RFCs that, only thinly obscuring the real message: "Leave this to the professionals and just use our custom libraries, or maybe an authentication SaaS".
In my opinion the text to code ratio is just really high. The standard itself isn't even that complex but hidden behind a huge wall of text. It's a bit sad that the most readable OAuth2 docs are from auth0.com.
The message would in principle even make sense if there was a real-world standard that was consistently adopted. Then not every SaaS would have to implement OAuth2 for the millionth time...
At one time, this was my product.. and oof, this one still hurts.
Section 5.1 of the OIDC spec says the standard claims can be in the ID token and/or at the Userinfo endpoint. Further, Section 2 says "ID Tokens MAY contain other Claims."
Unfortunately, one of the most common use cases for the ID token was to add someone's Groups, usually from AD. We had a number of customers with users who had a LOT of groups. I remember one where their users were in an average of 700 groups and one user had ~9000. These groups could be anything from the AD group created yesterday for a new app to that group from 15 years ago that no one wanted to delete just in case. This made for gigantic tokens.
Anyway, to address this scenario, someone at Okta came up with concept of the "fat ID token" and the "thin ID token". The "thin" would always come back with the access token on the inital request and the "fat" would only be available via the userinfo endpoint where we weren't limited by payload sizes.
We were using AWS Cognito and had to make a "pre-token-generation lambda" to filter out only the AD groups we cared about. We had a huge map of AD group IDs to our internal group names (multi-tenant application, so each client had a different AD group ids) so we filtered out the ad-groups and added a new custom claim with our internal names.
Fun that one time where we gave admin access to some people that shouldn't have it.
Before we added that map some of our user's tokens were exceeding the limits for AWS Cloudfront cache keys.
Cosign. AAD ID tokens had the same issue, and we'd see tokens with 1500+ guids shoved in there for the group ids. We had (and have) a nasty "too many, go call this API you need a new permission for" outcome there.
Right next to those customers were the ones demanding our tokens always be an exact number of bytes (yeah. Really).
The other challenge was customers who wanted groups to show up in a particular order. Since it's was literally just an array (no keys), it was just a giant alphabetized list.
Then the problem came when people used group count limits. Your group "AppDev" was always fine but "TestGroup7" may not be.. depending on how many groups the user was in and/or how they filtered those groups.
People talking about API design: zillions of good discussions online, papers written, standards created, thousands of hours of talks at dev conferences, heated debates that nearly venture into philosophy.
People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_/¯
I know that the people giving talks at strangeloop aren’t always the same people that implement OAuth, but still!! What’s it all for?
One guy’s PhD dissertation made us switch from XML to JSON, but beyond that you can rarely count on standards. Least of all REST, even when an API is supposedly REST.
Setting up about a dozen OAuth connections to social media ad platforms this year has made me realize that if an API is not a direct revenue stream, it is likely to be pretty bad. And have out-of-date or incomplete documentation.
Some of it is confusion about what say a 404 entails, is it the endpoint that does not exist, or that say /api/users returns an empty array for the given search parameters. Some libraries even throw an error if they receive a 404.
Probably ambiguity in the HTTP spec.
You’re totally right, but that was just an example I picked from the linked post. GitHub in my experience is pretty good.
But I’ve done a lot of exploring of social media marketing API, and you usually can’t rely on any amount of consistency or convention.
At work we have a running doc called “API weirdness” for each platform, where we document the many many undocumented behaviors that will throw you off for a day or two.
Reddit is particularly bad. Most of the useful “documentation” is found deep in threads in Reddit itself. Critical bits of information, including the very existence of some endpoints, are only explained in replies written by users!
The disconnect is simple: you have two populations. One is about consulting, coaching, writing books and speaking at conference to make money. The other is about cranking out code to get things done before some deadline.
People talking about API design: zillions of good discussions online, papers written, standards created, thousands of hours of talks at dev conferences, heated debates that nearly venture into philosophy.
People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_/¯
Those two are not contradictory; the latter is firmly on the side of the debate which treats HTTP strictly as transport, and considers mapping RPC errors to HTTP errors as a layering violation, inviting ambiguity and semantic mismatches. FWIW, I also subscribe to that view for RPC-shaped requests. If you receive a 200, you know that the request went through to the API server, and didn't become sidetracked on the HTTP level.
That’s fair, I picked a bad example from the linked article. GitHub is actually pretty good. But if you’ve done any digging around LinkedIn/twitter/Reddit’s API, you’ll know that there are many many quirks that will pop up and cost you days of frustration. Quirks that are not inspired by any particular design philosophy, unless that philosophy is “let’s fuck with our users” lmao
> One guy’s PhD dissertation made us switch from XML to JSON
The PhD dissertation was a rallying cry, something you could point the PhB to as a "best practice". Wanting to switch from XML to JSON had nothing to do with that dissertation, and most of the stuff in there does more harm than good.
My personal favorite is a provider that opted to have a separate endpoint for refesh tokens rather than following the spec and using the token endpoint with a refesh token grant type.
I'm not privy to GP's use case, but the "non-standard" part you nodded at makes it far more likely they "rolled their own crypto" and thus the landscape of vulns or leaks introduced by the "how hard can it be" crew is vast. That's not even including the similar, although smaller, risk pushed down upon the consumers since they are also now have to eject from the vetted libraries to interact and start doing their own fun //FIXME hacks
What? That's token to self, you don't even really need an access token there. What's the actual use case for an access token where the client and the resource are the same app? (I'm aware of some, but we didn't expect most folks would follow that flow)
I wonder whether the reason for this is a lack of available certified oauth libraries on top of which to build a provider at the time it was built, which led most of these examples to roll their own, with the obvious flaws. There isn't yet such a certification for oauth, although the oidc federation certifies and lists a bunch of them: https://openid.net/developers/certified-openid-connect-imple... (I maintain one of them). Which is the next best thing.
Giving a talk about this today. Biggest problem imho is the fact there were over 33 revisions, and now over 20 RFCs related to oauth. Developing to spec is hard when you don’t realize how big the spec is.
> Your server, for whatever fucking reason, returns a string for the token expiration.
5 dollars it is midlevel developers at a finance company who used quoted strings because they were told to do that for numbers, by people that had good intentions (they were trying to avoid using floats for financial information) but now the mid levels don't understand the basis for the rule they are following.
I wish OAuth said something about what to do when someone signs up with email/pass and then logs in using the same email via OAuth later. I get that this is outside the scope of the spec but it would be helpful if there were a standard around this. My opinion: merge the accounts and allow the user to login either way.
Ideally, you have a flow where you ask the user to input their password to confirm ownership, then merge. Otherwise, you're allowing the OAuth provider to back-door into established accounts.
Ah, yes fixing problems of one specific language at the protocol layer (and violating the spec). JSON isn't inherently limited to 2^52, JSON parsing in some languages and libraries are.
Arguably it's not some random language we are talking about, the JS in JSON means JavaScript after all ^^
Also the fact that there is no defined limit is more a bug of the spec that of implementations. In reality there is always a limit (at most the ram of involved computers) so not defining a specific max size is asking for trouble.
It requires the first party to the credential validation, for one thing. That means you have to have a separate account for every service, or expose your password for your shared account to those services.
In so much as every client now has to write custom code for every provider, yes. That's a massive maintenance burden, and a massive pain for customers when their preferred OAuth provider isn't supported by random clients.
This is pretty much the whole point of having specifications in the first place.
What is the problem with that? You know that the client credentials flow will normally just send the exact same information, principal and secret, in the form, right? How is sending a header with the information bad, specially when it was being done for ages already in this use case?
Your shopping cart receipt is almost wrong 100% of the time but no one checks or cares for a dollar or two. This is the same. See what they say back vs just a status code check. In spirit you are correct, however so SO SO many APIs return 200 when you have to check the return payload contents. - signed also frustrated API user
We can strong-arm their argument a bit. It's not true for me in particular because I buy a couple items every day or three instead of less frequently in a large shopping cart [0] and tend to buy items with known prices where I don't feel like I'm being scammed, but I still see errors every week or two, which should approximately correspond to an error every 2-week-cadence shopping trip. Common examples:
1. This isn't an issue where I currently live, but it's a problem in a subset of stores in maybe 1/10 cities I visit. Some stores routinely get state/local taxes blatantly wrong, even mega-chains like WalMart. They charge you one thing (coincidentally, never _less_ than the actual sales taxes owed) and remit a different amount to the governing body. These aren't small changes; it's charging an extra 1-3% on every transaction. The problem usually persists for years, I assume because the store isn't incentivized to fix it, enforcement is slow, the damage is low enough for each individual that lawsuits aren't worth it, and the damage takes long enough to build up that the overhead of a class action isn't worth it immediately either.
2. Much more frequently, stores get the tax wrong on "classes" of goods (e.g., the dividing line between tax-free grocery items and other foods). This is, perhaps, understandable given the number of unique items being sold, but it's very common for a grocery item to be inappropriately taxed.
3. The textual description of a sale is usually a bit different from how it's configured at the register. This matters more at stores like Safeway where the "sale" price just drops things down closer to the actual retail price of an item, and where there's a rotation of most items being on sale. Sometimes this is benign (a sale sticker doesn't have physical space for a lot of nuance), but some are more blatantly problematic. One example: Most sales don't have item caps (if a can of beans is on sale, I can buy both of them and have them both discounted), most exceptions are explicitly listed (e.g., "max 6 ears of corn per customer"), but sometimes things fall through the gaps, and the listed price will only apply to 1 out of the 3 things you purchased, leading to a surprise at the register. Another example: Required quantities are usually wrong. I remember one instance of needing to by "2lbs of chicken" of a particular variety, there only being one pack available (which happened to be 4lbs), and being told at the register that you had to buy 2 packs -- the fact that the sale couldn't be executed because they didn't stock enough was annoying (not common IME with chicken, more common at that store with other goods) but understandable, but the fact that the units were blatantly wrong and couldn't be discovered till you brought a refrigerated good to the register is a lot worse.
4. Mis-stocking causes a lot of confusion. Sometimes it's obvious which price goes where, so a careful shopper can avoid issues before the register, but sometimes the description attached to the price tag perfectly matches the item (and, if you search around, apparently several other items in the store) but is intended to refer to a different item. Barcodes don't lie though, and when you bring the wrong bottle of wine to the register you can get a nasty price shock.
5. Malicious rounding is pervasive. Last I checked (it's been a number of years), Amazon always rounds up on taxes as an example, which is an incorrect and illegal calculation in most US jurisdictions. Physical retailers behave similarly.
And so on. It's usually a matter of pennies. Sometimes it's a matter of $10-$100. Stores make many small mistakes, maybe maliciously, maybe not. Do with that information what you will.
[0] Not really relevant to the point at hand, but doing so fits better into my lifestyle. Stores aren't ever busy during my lunch break, by shopping so frequently I know instantly where everything is and can get through the store in minutes, my fruits and veggies are always fresh, it's easy to tailor meals to what I need to use up first, and for personal health I like to walk/bike 30-60min every day anyway with the shopping trip serving as an excuse.
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.
I'm in the exact same boat right now. I'm too lazy to fix it, so this is basically the only reason I still have my FB account.
Sounds like a win from a product perspective, higher retention! Clearly a feature, not a bug. The metrics don’t lie! /s
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.
Sometimes. It depends on how they bind your account. On the projects I’ve worked on, we’d always “upgrade” but I’ve seen plenty of sites that just create a new account. A behavior I find very annoying.
I have noticed a trend in many sites to reduce the number of social signin options down to maybe google (for android) and apple (for iOS) plus email / password. I suspect the “which signin method did I use” is one of the main reasons. That and clutter reduction.
By the way one of the big reasons a site might push you toward social signin is because those accounts are usually already verified. When you run through your own email / password flow you need to verify the email yourself (if that is important to your product). It’s an extra step that doesn’t need to happen when you click the magic google / apple button.
Key word is "often", I have heard too many stories where that is not the case.
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)
Disclosure, I work in this space, for a company called FusionAuth.
> 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.
>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.
today gmail, next month fastmail, next year self hosted.
once I move off of gmail, all the google oauth stuff breaks. So yea, you might today be beholden to one, but that can easily change
> And which email provider are you using? You rely on them too, right?
Not really, as I use my own domain so can just move that between providers. Exactly because I also don't want to be beholden to a free mail provider either.
> Personally I'm a big fan of letting someone log in any which way they want.
Sure, if people do want to use oauth by all means the should. I just don't think the short term signup convenience outweighs the longer term stuff like:
- annoyances of remembering how you signed up, the initial context I replied to.
- Having a extra service mixed in
- The privacy implications of your oauth provider having a neat list of the services you use.
> 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...
Not relevant to me as a user ;) I get why companies provide it. I just choose not to for the reasons already mentioned.
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.
I found once I started using a cross-device password manager, I stopped using OAuth anyway!
1 password does this automatically
If you use a password manager (and my condolences to those who don't), there's really no benefit to using OAuth over an email sign up. It can prepopulate your personal information, but I usually don't want that for the services I sign up for.
There's a couple of services where I prefer to use github for sso because I need them to integrate with data stored there, and it makes sense to me to "bundle" those accounts. But that's very much an edge case.
Is this where I complain about companies that insist I install their MFA app rather than just letting me use Google Authenticator? You're not special.
> there's really no benefit to using OAuth over an email sign up
Except for the really big one, which is strong MFA provided by the identity provider even when the site doesn't support it natively.
I do the same. I'm happy with it. I thank my past self every time for having the foresight that future self would forget.
I don't know about other password managers, but 1Password can track this for you automatically.
1password's browser extension attempts to record this for you.
Agreed, I have seen some sites check the email used and link the account instead of creating a new one. I much prefer this.
only works with email validation. Sadly some providers don’t do this (not even Microsoft azure ad in some cases…)
Some OAuth users, e.g. from Facebook, don't even have an email address associated with the account. Just a phone number.
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.
Easily preventable. Ask the user to supply a credential before linking the accounts or only allow account linking if the email is verified at the idp (as someone else noted this is not possible for all idps but for google it is)
Do any sites allow login from any OAuth provider? How would that even work? Providers need client IDs and client secrets.
The intent was probably "multiple", not "any".
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
Is that the right behaviour?
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?
If the attacker has hacked your email then they could presumably do a reset flow on gitlab and reset the password and clear any evidence. The identity provider step is unnecessary. If we assume that linking the salesforce account to gitlab generates an email. Then unless the attacker has persistent access to the email account you’d know about it. If they have persistent access then the existence of the linked account doesn’t matter. They can just do password resets whenever. This does assume linking an account generates an email. MFA or forced authentication with existing account to link a new identity provider makes sense. But in terms of password reset a hacked email is pretty much the keys to the kingdom anyway.
I suppose the slight difference is that with the password reset flow you’d know that you couldn’t login. But nine times out of ten I’d imagine you’d just do your own password reset upon finding you couldn’t login.
You have to verify access to the email with a code to do the merge. That solves your issue
But what if the attacker deleted the verification email after they merged the GitLab accounts? Then they still have a backdoor to your GitLab.
As far as I can see you are assuming an attacker with permanent access to your main email account.
If someone has persistent to your main email account you will have all kinds of problems.
I agree sibling comments are not quite correct about persistent email access. You could fix the email problem while the "backdoor" to Gitlab remains.
The problem statement says this about corrective action:
>I discover the hack and change the passwords on every account I know about
In actuality, the corrective action is to change the passwords and revoke any SSO integrations.
To the original point, this does add more overhead to the process, probably isn't obvious to most people, and depends on the site having clear UI for the topic.
As somebody else said, once your email is compromised you are fucked and have far larger problems than a single individual site.
No. No. God no. Do not ever do that.
The email address you get from an oauth provider should never be trusted.
Mostly but not entirely true. If Google oauth gives you an @gmail.com email, you can trust it.
A more accurate formulation would be: the email address you get from an oauth provide must not be trusted unless the oauth provider controls the email domain and guarantees no re-use of addresses.
Not that it’s practical to special case every such provider, but with Gmail handling 25% of email, there can be good UX affordances for them a few others.
Even in the case of gmail, which is the best case, you can not be sure the person in control of the Google account is the same as the one that used that gmail address to create an account on your site. The person might have got their Google account hacked, they might have used a shared gmail account to sign up, your service might not have been properly verifying email addresses when they signed up, etc.
But yes, to be fair, if you have email-based password reset functionality, it is not really an additional security vulnerability.
Control of the Gmail account and ability to get an oath token for that account are one at the same, as far as I know. Both indicate you’ve authenticated as that user with Google.
There are a few others. I’m not sure it’s worth the special casing, but it can be a better user experience.
'Never' is a bit strong. It depends a lot on what you're using the email address for. And it's probably safe to trust gmail addresses coming from google, for instance.
What I did, was write logic to link accounts together via an automatic email confirmation.
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
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.
this is why Matrix is switching to native OIDC rather than the current messy mix: https://areweoidcyet.com
>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.
A year ago we implemented OAuth for 100 popular APIs.
Our experience was exactly like OP describes: https://www.nango.dev/blog/why-is-oauth-still-hard
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.
Almost the exact same sentiment as yours, but from an earlier conversation, and it really stuck with me.
“… 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
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.
The RFC reads very much like a spec and not like a rough guideline. What are you talking about when you say guideline?
I've read the RFCs several years back and they did not feel clearly written, not like a protocol spec. Maybe it was just me. The reality is each OAuth implementation is unique. Almost no two are the same.
All the problems mentioned in the blog post are due to the providers not following what the spec clearly said.
If you have an example of where that's not the case, I would also love to hear as I work in this area (perhaps you're thinking about how OAuth does not specify at all how authentication happen? But that was a good call, OAuth 1 did and it was too limiting... also OpenID Connect is pretty widely adopted now, and it fills that gap well).
"Clearly" is relative. If all these providers are having problems with the spec... what does that tell you?
What that tells me is that people who cannot read and understand a specification (or willingly ignore what the spec says) are implementing it anyway. I claim the spec is completely clear on all the points raised in the blog post. You can't just handwave that away without specifically telling what point was unclear.
Just imagine if we had these problems with TCP!
It's how people follow something that says what it is.
The RFC is not what people actually implement.
Hey I've made a weird OAuth like that!
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.
It’s a small thing, but in my eyes you are a hero
OAuth is already Frankenstein by itself, you just made a slightly differently colored Frankenstein.
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.
It absolutely grinds my gears - Chrome's profile system and / or Firefox's container tab system work somewhat, but it feels like a bandaid fix.
Do you want select account, implying the site supports multiple accounts at a time, or just prompt=login?
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.
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.
For open standards like this, it would really help if there was an official, readily available test suite anyone could run.
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.
Like this: https://openid.net/certification/about-conformance-suite/
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.
I take it that you've never lost a domain.
Emergency reserve military duty, a sudden sickness, email delivery issues, or even a temporary financial problem at the wrong time of year could all be reasons to missing the domain renewal window. It's happened to people far smarter than me.
Pay ahead for 20 years?
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.
My guess is the JSON serializer uses strings for int64s to avoid loss of precision.
"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.
https://github.com/pilcrowonpaper/pilcrow/commit/29b105e9c12... "remove aws"
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.
It must be a JSON object with an error field.
What you showed is exactly that. Does the spec say the field must be a string?
As the sibling comment says: not just that it's a string, but which strings are expected.
OIDC extends the list with a few more: https://openid.net/specs/openid-connect-core-1_0.html#AuthEr...
This allows clients to interop with any server. Doing the shit Facebook is doing completely ignores one of the main objectives of implementing a RFC: interoperability.
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1
It's in Section 5, actually. That one is for the implicit-grant flow, so the fields are URL-encoded and appended to the redirect URI's query fragment.
Yep, from section 5:
> error
> REQUIRED. A single ASCII [USASCII] error code from the following...
Dear OIDC/OAuth Providers, please do proper support for SCIM, design your systems with "API first mindset" and let me design my routes for redirects and embedded login functionality ... before you move onto GNAP (Grant Negotiation and Authorization Protocol) https://oauth.net/gnap/ ... reconsider your decisions
OAuth is such a bad standard, if you even want to call a loosely cross-referenced bundle of RFCs that, only thinly obscuring the real message: "Leave this to the professionals and just use our custom libraries, or maybe an authentication SaaS".
In my opinion the text to code ratio is just really high. The standard itself isn't even that complex but hidden behind a huge wall of text. It's a bit sad that the most readable OAuth2 docs are from auth0.com.
The message would in principle even make sense if there was a real-world standard that was consistently adopted. Then not every SaaS would have to implement OAuth2 for the millionth time...
Which are buggy as hell
Dear Okta, please include your OIDC profile claims in your ID tokens.
Actually no, that's on the spec for not enforcing they're in the ID token, and only must be available in the userinfo endpoint.
At one time, this was my product.. and oof, this one still hurts.
Section 5.1 of the OIDC spec says the standard claims can be in the ID token and/or at the Userinfo endpoint. Further, Section 2 says "ID Tokens MAY contain other Claims."
Unfortunately, one of the most common use cases for the ID token was to add someone's Groups, usually from AD. We had a number of customers with users who had a LOT of groups. I remember one where their users were in an average of 700 groups and one user had ~9000. These groups could be anything from the AD group created yesterday for a new app to that group from 15 years ago that no one wanted to delete just in case. This made for gigantic tokens.
Anyway, to address this scenario, someone at Okta came up with concept of the "fat ID token" and the "thin ID token". The "thin" would always come back with the access token on the inital request and the "fat" would only be available via the userinfo endpoint where we weren't limited by payload sizes.
So yeah, now you know and sorry about that.
I knew we documented it somewhere:
https://developer.okta.com/docs/concepts/api-access-manageme...
We were using AWS Cognito and had to make a "pre-token-generation lambda" to filter out only the AD groups we cared about. We had a huge map of AD group IDs to our internal group names (multi-tenant application, so each client had a different AD group ids) so we filtered out the ad-groups and added a new custom claim with our internal names.
Fun that one time where we gave admin access to some people that shouldn't have it.
Before we added that map some of our user's tokens were exceeding the limits for AWS Cloudfront cache keys.
Cosign. AAD ID tokens had the same issue, and we'd see tokens with 1500+ guids shoved in there for the group ids. We had (and have) a nasty "too many, go call this API you need a new permission for" outcome there.
Right next to those customers were the ones demanding our tokens always be an exact number of bytes (yeah. Really).
Ha, I dealt with some of those.
The other challenge was customers who wanted groups to show up in a particular order. Since it's was literally just an array (no keys), it was just a giant alphabetized list.
Then the problem came when people used group count limits. Your group "AppDev" was always fine but "TestGroup7" may not be.. depending on how many groups the user was in and/or how they filtered those groups.
Figuring out that one out was terrible.
A disconnect I often wonder about:
People talking about API design: zillions of good discussions online, papers written, standards created, thousands of hours of talks at dev conferences, heated debates that nearly venture into philosophy.
People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_/¯
I know that the people giving talks at strangeloop aren’t always the same people that implement OAuth, but still!! What’s it all for?
One guy’s PhD dissertation made us switch from XML to JSON, but beyond that you can rarely count on standards. Least of all REST, even when an API is supposedly REST.
Setting up about a dozen OAuth connections to social media ad platforms this year has made me realize that if an API is not a direct revenue stream, it is likely to be pretty bad. And have out-of-date or incomplete documentation.
Some of it is confusion about what say a 404 entails, is it the endpoint that does not exist, or that say /api/users returns an empty array for the given search parameters. Some libraries even throw an error if they receive a 404. Probably ambiguity in the HTTP spec.
You’re totally right, but that was just an example I picked from the linked post. GitHub in my experience is pretty good.
But I’ve done a lot of exploring of social media marketing API, and you usually can’t rely on any amount of consistency or convention.
At work we have a running doc called “API weirdness” for each platform, where we document the many many undocumented behaviors that will throw you off for a day or two.
Reddit is particularly bad. Most of the useful “documentation” is found deep in threads in Reddit itself. Critical bits of information, including the very existence of some endpoints, are only explained in replies written by users!
The disconnect is simple: you have two populations. One is about consulting, coaching, writing books and speaking at conference to make money. The other is about cranking out code to get things done before some deadline.
People talking about API design: zillions of good discussions online, papers written, standards created, thousands of hours of talks at dev conferences, heated debates that nearly venture into philosophy.
People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_/¯
Those two are not contradictory; the latter is firmly on the side of the debate which treats HTTP strictly as transport, and considers mapping RPC errors to HTTP errors as a layering violation, inviting ambiguity and semantic mismatches. FWIW, I also subscribe to that view for RPC-shaped requests. If you receive a 200, you know that the request went through to the API server, and didn't become sidetracked on the HTTP level.
Also, the OAuth RFC does not use "MUST" for 400 response and allows some freedom in this regard:
> The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise)
https://datatracker.ietf.org/doc/html/rfc6749#section-5.2
That’s fair, I picked a bad example from the linked article. GitHub is actually pretty good. But if you’ve done any digging around LinkedIn/twitter/Reddit’s API, you’ll know that there are many many quirks that will pop up and cost you days of frustration. Quirks that are not inspired by any particular design philosophy, unless that philosophy is “let’s fuck with our users” lmao
> One guy’s PhD dissertation made us switch from XML to JSON
The PhD dissertation was a rallying cry, something you could point the PhB to as a "best practice". Wanting to switch from XML to JSON had nothing to do with that dissertation, and most of the stuff in there does more harm than good.
> People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_/¯
Or people implement it correctly, and somebody puts a machine on the middle that converts everything into a 200 response.
The web is not a well-behaved platform.
My personal favorite is a provider that opted to have a separate endpoint for refesh tokens rather than following the spec and using the token endpoint with a refesh token grant type.
Besides being slightly annoying and non-standard (so obviously don't do that), is there any security issues introduced by doing so?
I'm not privy to GP's use case, but the "non-standard" part you nodded at makes it far more likely they "rolled their own crypto" and thus the landscape of vulns or leaks introduced by the "how hard can it be" crew is vast. That's not even including the similar, although smaller, risk pushed down upon the consumers since they are also now have to eject from the vetted libraries to interact and start doing their own fun //FIXME hacks
Another one: Microsoft azure not wanting to send you an access token in the "Token Endpoint" unless you inject the client_id in the scope ....
Hear. This one! So many of customers have been stabbed in the back with this one
What? That's token to self, you don't even really need an access token there. What's the actual use case for an access token where the client and the resource are the same app? (I'm aware of some, but we didn't expect most folks would follow that flow)
I wonder whether the reason for this is a lack of available certified oauth libraries on top of which to build a provider at the time it was built, which led most of these examples to roll their own, with the obvious flaws. There isn't yet such a certification for oauth, although the oidc federation certifies and lists a bunch of them: https://openid.net/developers/certified-openid-connect-imple... (I maintain one of them). Which is the next best thing.
Giving a talk about this today. Biggest problem imho is the fact there were over 33 revisions, and now over 20 RFCs related to oauth. Developing to spec is hard when you don’t realize how big the spec is.
https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
Had you linked to the only .md in that gist it would have set expectations what the otherwise meaningless URL was attempting to say https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
> (Scraped from the Internet Wayback Machine. Original content by Eran Hammer / hueniverse.com July 26, 2012)
> OAuth 2.0 and the Road to Hell
Fat chance of them changing this now, Hyrum’s law says someone is depending on this.
https://www.hyrumslaw.com/
If you consider the newest rfc9068: https://datatracker.ietf.org/doc/html/rfc9068 for JWT profiled Access Token, the list of discrepancies is even longer.
> Your server, for whatever fucking reason, returns a string for the token expiration.
5 dollars it is midlevel developers at a finance company who used quoted strings because they were told to do that for numbers, by people that had good intentions (they were trying to avoid using floats for financial information) but now the mid levels don't understand the basis for the rule they are following.
I wish OAuth said something about what to do when someone signs up with email/pass and then logs in using the same email via OAuth later. I get that this is outside the scope of the spec but it would be helpful if there were a standard around this. My opinion: merge the accounts and allow the user to login either way.
Ideally, you have a flow where you ask the user to input their password to confirm ownership, then merge. Otherwise, you're allowing the OAuth provider to back-door into established accounts.
Good call. I had not considered the OAuth provider acting nefariously.
Dear telegram! Why you have something that resembles OAuth, but not OAuth? Please create OAuth compliant endpoint. Thank you
The string token expiration is useful if you need expiration duration over 2^52 seconds ;)
Ah, yes fixing problems of one specific language at the protocol layer (and violating the spec). JSON isn't inherently limited to 2^52, JSON parsing in some languages and libraries are.
Arguably it's not some random language we are talking about, the JS in JSON means JavaScript after all ^^
Also the fact that there is no defined limit is more a bug of the spec that of implementations. In reality there is always a limit (at most the ram of involved computers) so not defining a specific max size is asking for trouble.
Been considering a switch to stalw.art for my personal mail server since it can also act as an IdP. Wonder how this author would it.
If you get this command to output anything during install, please let me know: "docker logs stalwart-mail"
Have reached out on multiple channels and only crickets.
What's the general sentiment, is the basic auth not done by some because it's considered weak security?
It requires the first party to the credential validation, for one thing. That means you have to have a separate account for every service, or expose your password for your shared account to those services.
AFAIK. YMMV.
You also have to store the plaintext password Somewhere. Same problem with DIGEST.
Where did you get this from? You know how passwords are matched right?
What? Why?
I could add at least 10 more to this list, just based on my personal experience
Is is a big concern that these providers are not spec compliant?
In so much as every client now has to write custom code for every provider, yes. That's a massive maintenance burden, and a massive pain for customers when their preferred OAuth provider isn't supported by random clients.
This is pretty much the whole point of having specifications in the first place.
Discord also doesn't work with Firebase OIDC.
Had such a good laugh with this :D
Thank you.
You had me until "Please support HTTP basic auth for client authentication".
OAuth 2.1 draft spec emphasizes that basic auth is no longer preferred. I read that to mean: MAY, or perhaps even SHOULD NOT.
What is the problem with that? You know that the client credentials flow will normally just send the exact same information, principal and secret, in the form, right? How is sending a header with the information bad, specially when it was being done for ages already in this use case?
> How is sending a header with the information bad, specially when it was being done for ages already in this use case?
leeches
(To actually answer your question, there are a number of tricks you can use to prevent abuse that aren't effective when using http basic)
Always read the receipt.
Your shopping cart receipt is almost wrong 100% of the time but no one checks or cares for a dollar or two. This is the same. See what they say back vs just a status code check. In spirit you are correct, however so SO SO many APIs return 200 when you have to check the return payload contents. - signed also frustrated API user
Your shopping cart receipt is wrong 100% of the time is an insane claim.
This is proved day in and day out. Im sorry but you are 100% wrong here.
We can strong-arm their argument a bit. It's not true for me in particular because I buy a couple items every day or three instead of less frequently in a large shopping cart [0] and tend to buy items with known prices where I don't feel like I'm being scammed, but I still see errors every week or two, which should approximately correspond to an error every 2-week-cadence shopping trip. Common examples:
1. This isn't an issue where I currently live, but it's a problem in a subset of stores in maybe 1/10 cities I visit. Some stores routinely get state/local taxes blatantly wrong, even mega-chains like WalMart. They charge you one thing (coincidentally, never _less_ than the actual sales taxes owed) and remit a different amount to the governing body. These aren't small changes; it's charging an extra 1-3% on every transaction. The problem usually persists for years, I assume because the store isn't incentivized to fix it, enforcement is slow, the damage is low enough for each individual that lawsuits aren't worth it, and the damage takes long enough to build up that the overhead of a class action isn't worth it immediately either.
2. Much more frequently, stores get the tax wrong on "classes" of goods (e.g., the dividing line between tax-free grocery items and other foods). This is, perhaps, understandable given the number of unique items being sold, but it's very common for a grocery item to be inappropriately taxed.
3. The textual description of a sale is usually a bit different from how it's configured at the register. This matters more at stores like Safeway where the "sale" price just drops things down closer to the actual retail price of an item, and where there's a rotation of most items being on sale. Sometimes this is benign (a sale sticker doesn't have physical space for a lot of nuance), but some are more blatantly problematic. One example: Most sales don't have item caps (if a can of beans is on sale, I can buy both of them and have them both discounted), most exceptions are explicitly listed (e.g., "max 6 ears of corn per customer"), but sometimes things fall through the gaps, and the listed price will only apply to 1 out of the 3 things you purchased, leading to a surprise at the register. Another example: Required quantities are usually wrong. I remember one instance of needing to by "2lbs of chicken" of a particular variety, there only being one pack available (which happened to be 4lbs), and being told at the register that you had to buy 2 packs -- the fact that the sale couldn't be executed because they didn't stock enough was annoying (not common IME with chicken, more common at that store with other goods) but understandable, but the fact that the units were blatantly wrong and couldn't be discovered till you brought a refrigerated good to the register is a lot worse.
4. Mis-stocking causes a lot of confusion. Sometimes it's obvious which price goes where, so a careful shopper can avoid issues before the register, but sometimes the description attached to the price tag perfectly matches the item (and, if you search around, apparently several other items in the store) but is intended to refer to a different item. Barcodes don't lie though, and when you bring the wrong bottle of wine to the register you can get a nasty price shock.
5. Malicious rounding is pervasive. Last I checked (it's been a number of years), Amazon always rounds up on taxes as an example, which is an incorrect and illegal calculation in most US jurisdictions. Physical retailers behave similarly.
And so on. It's usually a matter of pennies. Sometimes it's a matter of $10-$100. Stores make many small mistakes, maybe maliciously, maybe not. Do with that information what you will.
[0] Not really relevant to the point at hand, but doing so fits better into my lifestyle. Stores aren't ever busy during my lunch break, by shopping so frequently I know instantly where everything is and can get through the store in minutes, my fruits and veggies are always fresh, it's easy to tailor meals to what I need to use up first, and for personal health I like to walk/bike 30-60min every day anyway with the shopping trip serving as an excuse.
Oops, strong-arm -> steel-man
A penny or two I'd understand but I think even that'd be wrong, but a dollar or two? Absolutely false.