Dear OAuth Providers
pilcrowonpaper.com
pilcrowonpaper.com
It's inelegant and could be better, but good enough.
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.
Except for the really big one, which is strong MFA provided by the identity provider even when the site doesn't support it natively.
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?
If someone has persistent to your main email account you will have all kinds of problems.
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.
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.
The email address you get from an oauth provider should never be trusted.
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.
But yes, to be fair, if you have email-based password reset functionality, it is not really an additional security vulnerability.
There are a few others. I’m not sure it’s worth the special casing, but it can be a better user experience.
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 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.
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 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 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.
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
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.
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.
Try visiting this URL twice, but use two different login methods (that use the same address).
Our experience was exactly like OP describes: https://www.nango.dev/blog/why-is-oauth-still-hard
“… one of the principle issues is that it's less a protocol and more a skeleton of a protocol.”
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).
Source- done over 300 system connections. Save the straight API keys, they're all special and unique snowflakes.
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.
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 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.
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.
What you showed is exactly that. Does the spec say the field must be a string?
> error
> REQUIRED. A single ASCII [USASCII] error code from the following...
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.
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...
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.
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.
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.
https://developer.okta.com/docs/concepts/api-access-manageme...
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.
Figuring out that one out was terrible.
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.
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 ¯\_(ツ)_/¯
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.
> The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise)
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!
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.
> (Scraped from the Internet Wayback Machine. Original content by Eran Hammer / hueniverse.com July 26, 2012)
> OAuth 2.0 and the Road to Hell
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.
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.
Have reached out on multiple channels and only crickets.
AFAIK. YMMV.
This is pretty much the whole point of having specifications in the first place.
OAuth 2.1 draft spec emphasizes that basic auth is no longer preferred. I read that to mean: MAY, or perhaps even SHOULD NOT.
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)
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
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.