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.
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.
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.
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.
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)
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.
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 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.
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.
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.
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.
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)
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.
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.
>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.
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.
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.
> 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'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.
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?
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.
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.
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...
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 instant...
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
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 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.
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.
> 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.
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
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!
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.
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.
"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.
145 comments
[ 548 ms ] story [ 3434 ms ] threadWhat 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.
AFAIK. YMMV.
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).
https://auth.ai.moda/pages/v1.0.0/login
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.”
https://news.ycombinator.com/item?id=35720336
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.
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.
Have reached out on multiple channels and only crickets.
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.
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)
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.
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.
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...
https://www.hyrumslaw.com/
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 instant...
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)
https://datatracker.ietf.org/doc/html/rfc6749#section-5.2
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.
This is pretty much the whole point of having specifications in the first place.
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.
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.