16 ms·

Dear OAuth Providers

439 points by franciscop 2y ago

surbas 2y ago
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.
leosarev 2y ago
Dear telegram! Why you have something that resembles OAuth, but not OAuth? Please create OAuth compliant endpoint. Thank you
NewJazz 2y ago
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?
- Nijikokun 2y ago
  https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1 https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1
  - tadfisher 2y ago
    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.
    - marcellus23 2y ago
      Yep, from section 5: > error > REQUIRED. A single ASCII [USASCII] error code from the following...
- brabel 2y ago
  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#AuthError 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.
politelemon 2y ago
What's the general sentiment, is the basic auth not done by some because it's considered weak security?
- recursive 2y ago
  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.
  - whartung 2y ago
    You also have to store the plaintext password Somewhere. Same problem with DIGEST.
    - boopdewoop 2y ago
      Where did you get this from? You know how passwords are matched right?
    - 0x457 2y ago
      What? Why?
teeray 2y ago
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.
- boopdewoop 2y ago
  Agreed, I have seen some sites check the email used and link the account instead of creating a new one. I much prefer this.
  - lxgr 2y ago
    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.
  - merb 2y ago
    only works with email validation. Sadly some providers don’t do this (not even Microsoft azure ad in some cases…)
    - dotancohen 2y ago
      Some OAuth users, e.g. from Facebook, don't even have an email address associated with the account. Just a phone number.
  - eastbound 2y ago
    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.
    - ascorbic 2y ago
      Do any sites allow login from any OAuth provider? How would that even work? Providers need client IDs and client secrets.
rguldener 2y ago
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 https://www.nango.dev/blog/why-is-oauth-still-hard
- icedchai 2y ago
  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.
  - arwhatever 2y ago
    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 https://news.ycombinator.com/item?id=35720336
  - 7bit 2y ago
    The RFC reads very much like a spec and not like a rough guideline. What are you talking about when you say guideline?
    - icedchai 2y ago
      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.
      - brabel 2y ago
        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).
iforgotpassword 2y ago
> 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.
- __mattya 2y ago
  My guess is the JSON serializer uses strings for int64s to avoid loss of precision.
  - deleted 2y ago
    [deleted]
xyst 2y ago
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.
- artificialLimbs 2y ago
  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.
deleted 2y ago
[deleted]
Onavo 2y ago
Discord also doesn't work with Firebase OIDC.
jamamp 2y ago
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.
- datenyan 2y ago
  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.
- hirsin 2y ago
  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.
  - jamamp 2y ago
    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.
EmilienCosson 2y ago
Thank you.
magicalhippo 2y ago
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.
- d4nt 2y ago
  Like this: https://openid.net/certification/about-conformance-suite/ https://openid.net/certification/about-conformance-suite/
  - Terr_ 2y ago
    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.
    - dotancohen 2y ago
      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.
      - Aeolun 2y ago
        Pay ahead for 20 years?
ryanmarsh 2y ago
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.
- brabel 2y ago
  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?
  - grayhatter 2y ago
    > 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)
jamamp 2y ago
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.
- caseysoftware 2y ago
  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.
  - DanielHB 2y ago
    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.
  - caseysoftware 2y ago
    I knew we documented it somewhere: https://developer.okta.com/docs/concepts/api-access-management/#tokens-and-scopes https://developer.okta.com/docs/concepts/api-access-manageme...
SeenNotHeard 2y ago
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.
lxgr 2y ago
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".
- siva7 2y ago
  Which are buggy as hell
- blablabla123 2y ago
  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...
dvektor 2y ago
Had such a good laugh with this :D
MarkMarine 2y ago
Fat chance of them changing this now, Hyrum’s law says someone is depending on this. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
ProAm 2y ago
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
- portaouflop 2y ago
  Your shopping cart receipt is wrong 100% of the time is an insane claim.
  - hansvm 2y ago
    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.
adeptima 2y ago
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/ https://oauth.net/gnap/ ... reconsider your decisions
mickael-kerjean 2y ago
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 ....
- authnopuz 2y ago
  Hear. This one! So many of customers have been stabbed in the back with this one
- hirsin 2y ago
  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)
block_dagger 2y ago
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.
- solatic 2y ago
  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.
  - block_dagger 2y ago
    Good call. I had not considered the OAuth provider acting nefariously.
chamomeal 2y ago
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.
- lmm 2y ago
  > 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.
- arkh 2y ago
  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.
- inejge 2y ago
  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.
taz123 2y ago
Is is a big concern that these providers are not spec compliant?
- swiftcoder 2y ago
  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.
forty 2y ago
The string token expiration is useful if you need expiration duration over 2^52 seconds ;)
- badmintonbaseba 2y ago
  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.
  - forty 2y ago
    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.
weinzierl 2y ago
"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.
- suzzer99 2y ago
  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.
- mdaniel 2y ago
  https://github.com/pilcrowonpaper/pilcrow/commit/29b105e9c1255772648c81eb87e9f056e3802bde https://github.com/pilcrowonpaper/pilcrow/commit/29b105e9c12... "remove aws"
authnopuz 2y ago
If you consider the newest rfc9068: https://datatracker.ietf.org/doc/html/rfc9068 https://datatracker.ietf.org/doc/html/rfc9068 for JWT profiled Access Token, the list of discrepancies is even longer.
hhthrowaway1230 2y ago
https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
- mdaniel 2y ago
  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/dd2d4dfc86f7d13045ad715377b6a48f#file-eran-hammer-oauth2-rant-20120726-md 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
lukaszkorecki 2y ago
I could add at least 10 more to this list, just based on my personal experience
abap_rocky 2y ago
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.
- diggan 2y ago
  Besides being slightly annoying and non-standard (so obviously don't do that), is there any security issues introduced by doing so?
  - mdaniel 2y ago
    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
yuters 2y ago
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.
- chamomeal 2y ago
  It’s a small thing, but in my eyes you are a hero
- GoblinSlayer 2y ago
  OAuth is already Frankenstein by itself, you just made a slightly differently colored Frankenstein.
nailer 2y ago
> 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.
chucke 2y ago
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-implementations/ https://openid.net/developers/certified-openid-connect-imple... (I maintain one of them). Which is the next best thing.

439 points by franciscop 2y ago

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.

leosarev 2y ago

Dear telegram! Why you have something that resembles OAuth, but not OAuth? Please create OAuth compliant endpoint. Thank you

NewJazz 2y ago

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?

Nijikokun 2y ago
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1 https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1
- tadfisher 2y ago
  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.
  - marcellus23 2y ago
    Yep, from section 5: > error > REQUIRED. A single ASCII [USASCII] error code from the following...
brabel 2y ago
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#AuthError 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.

politelemon 2y ago

What's the general sentiment, is the basic auth not done by some because it's considered weak security?

recursive 2y ago
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.
- whartung 2y ago
  You also have to store the plaintext password Somewhere. Same problem with DIGEST.
  - boopdewoop 2y ago
    Where did you get this from? You know how passwords are matched right?
  - 0x457 2y ago
    What? Why?

teeray 2y ago

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.

boopdewoop 2y ago
Agreed, I have seen some sites check the email used and link the account instead of creating a new one. I much prefer this.
- lxgr 2y ago
  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.
- merb 2y ago
  only works with email validation. Sadly some providers don’t do this (not even Microsoft azure ad in some cases…)
  - dotancohen 2y ago
    Some OAuth users, e.g. from Facebook, don't even have an email address associated with the account. Just a phone number.
- eastbound 2y ago
  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.
  - ascorbic 2y ago
    Do any sites allow login from any OAuth provider? How would that even work? Providers need client IDs and client secrets.

rguldener 2y ago

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 https://www.nango.dev/blog/why-is-oauth-still-hard

icedchai 2y ago
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.
- arwhatever 2y ago
  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 https://news.ycombinator.com/item?id=35720336
- 7bit 2y ago
  The RFC reads very much like a spec and not like a rough guideline. What are you talking about when you say guideline?
  - icedchai 2y ago
    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.
    - brabel 2y ago
      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).

iforgotpassword 2y ago

> 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.

__mattya 2y ago
My guess is the JSON serializer uses strings for int64s to avoid loss of precision.
- deleted 2y ago
  [deleted]

xyst 2y ago

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.

artificialLimbs 2y ago
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.

deleted 2y ago

[deleted]

Onavo 2y ago

Discord also doesn't work with Firebase OIDC.

jamamp 2y ago

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.

datenyan 2y ago
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.
hirsin 2y ago
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.
- jamamp 2y ago
  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.

EmilienCosson 2y ago

Thank you.

magicalhippo 2y ago

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.

d4nt 2y ago
Like this: https://openid.net/certification/about-conformance-suite/ https://openid.net/certification/about-conformance-suite/
- Terr_ 2y ago
  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.
  - dotancohen 2y ago
    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.
    - Aeolun 2y ago
      Pay ahead for 20 years?

ryanmarsh 2y ago

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.

brabel 2y ago
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?
- grayhatter 2y ago
  > 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)

jamamp 2y ago

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.

caseysoftware 2y ago
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.
- DanielHB 2y ago
  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.
- caseysoftware 2y ago
  I knew we documented it somewhere: https://developer.okta.com/docs/concepts/api-access-management/#tokens-and-scopes https://developer.okta.com/docs/concepts/api-access-manageme...

SeenNotHeard 2y ago

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.

lxgr 2y ago

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".

siva7 2y ago
Which are buggy as hell
blablabla123 2y ago
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...

dvektor 2y ago

Had such a good laugh with this :D

MarkMarine 2y ago

Fat chance of them changing this now, Hyrum’s law says someone is depending on this. https://www.hyrumslaw.com/ https://www.hyrumslaw.com/

ProAm 2y ago

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

portaouflop 2y ago
Your shopping cart receipt is wrong 100% of the time is an insane claim.
- hansvm 2y ago
  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.

adeptima 2y ago

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/ https://oauth.net/gnap/ ... reconsider your decisions

mickael-kerjean 2y ago

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 ....

authnopuz 2y ago
Hear. This one! So many of customers have been stabbed in the back with this one
hirsin 2y ago
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)

block_dagger 2y ago

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.

solatic 2y ago
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.
- block_dagger 2y ago
  Good call. I had not considered the OAuth provider acting nefariously.

chamomeal 2y ago

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.

lmm 2y ago
> 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.
arkh 2y ago
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.
inejge 2y ago
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.

taz123 2y ago

Is is a big concern that these providers are not spec compliant?

swiftcoder 2y ago
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.

forty 2y ago

The string token expiration is useful if you need expiration duration over 2^52 seconds ;)

badmintonbaseba 2y ago
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.
- forty 2y ago
  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.

weinzierl 2y ago

"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.

suzzer99 2y ago
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.
mdaniel 2y ago
https://github.com/pilcrowonpaper/pilcrow/commit/29b105e9c1255772648c81eb87e9f056e3802bde https://github.com/pilcrowonpaper/pilcrow/commit/29b105e9c12... "remove aws"

authnopuz 2y ago

If you consider the newest rfc9068: https://datatracker.ietf.org/doc/html/rfc9068 https://datatracker.ietf.org/doc/html/rfc9068 for JWT profiled Access Token, the list of discrepancies is even longer.

hhthrowaway1230 2y ago

https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...

mdaniel 2y ago
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/dd2d4dfc86f7d13045ad715377b6a48f#file-eran-hammer-oauth2-rant-20120726-md 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

lukaszkorecki 2y ago

I could add at least 10 more to this list, just based on my personal experience

abap_rocky 2y ago

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.

diggan 2y ago
Besides being slightly annoying and non-standard (so obviously don't do that), is there any security issues introduced by doing so?
- mdaniel 2y ago
  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

yuters 2y ago

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.

chamomeal 2y ago
It’s a small thing, but in my eyes you are a hero
GoblinSlayer 2y ago
OAuth is already Frankenstein by itself, you just made a slightly differently colored Frankenstein.

nailer 2y ago

> 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.

chucke 2y ago

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-implementations/ https://openid.net/developers/certified-openid-connect-imple... (I maintain one of them). Which is the next best thing.