Dear OAuth Providers

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.

A year ago we implemented OAuth for 100 popular APIs.<p>Our experience was exactly like OP describes: <a href="https:&#x2F;&#x2F;www.nango.dev&#x2F;blog&#x2F;why-is-oauth-still-hard" rel="nofollow">https:&#x2F;&#x2F;www.nango.dev&#x2F;blog&#x2F;why-is-oauth-still-hard</a>

Hey I&#x27;ve made a weird OAuth like that!<p>It was an intranet with an OAuth server for a company. A team that implemented an OAuth login for another related app wouldn&#x27;t follow the official specs. They&#x27;ve asked for me to change how OAuth works because otherwise it would be &quot;impossible&quot; for them to implement the login, and what they were asking were seemingly random changes that didn&#x27;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.<p>In the end, I caved in, and there&#x27;s now an OAuth Frankenstein just for them that lives alongside the OAuth for everyone else. I&#x27;ve made a dedicated #special-needs section just for them in the docs, with no explanations why, and I hope other teams will enjoy the read.

I&#x27;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&#x27;s frustrating when you can&#x27;t easily log out of the destination IdP for, say, SSO.

For open standards like this, it would really help if there was an official, readily available test suite anyone could run.<p>Sure there&#x27;s the spec, but it&#x27;s a lot to keep track of for the intern that inevitably ends up implementing such things.<p>Having a test suite you to verify you didn&#x27;t mess up would be very useful.

Some of these problems (esp. Facebook&#x27;s) look like someone used an existing service framework to code OAuth2, and either didn&#x27;t or couldn&#x27;t adjust the framework to conform to spec.<p>Some of the other problems look like a common problem with scripting—the ease of treating an int like a string, and vice-versa.<p>&quot;This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision.&quot;<p>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.

&gt; This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision. And also please fix it.<p>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>&quot;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.&quot;</i><p>I wish the section would have been kept. I don&#x27;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.

<i>It must be a JSON object with an error field.</i><p>What you showed is exactly that. Does the spec say the field must be a string?

Dear OIDC&#x2F;OAuth Providers, please do proper support for SCIM, design your systems with &quot;API first mindset&quot; and let me design my routes for redirects and embedded login functionality ... before you move onto GNAP (Grant Negotiation and Authorization Protocol) <a href="https:&#x2F;&#x2F;oauth.net&#x2F;gnap&#x2F;" rel="nofollow">https:&#x2F;&#x2F;oauth.net&#x2F;gnap&#x2F;</a> ... reconsider your decisions

OAuth is such a bad standard, if you even want to call a loosely cross-referenced bundle of RFCs that, only thinly obscuring the real message: &quot;Leave this to the professionals and just use our custom libraries, or maybe an authentication SaaS&quot;.

Dear Okta, please include your OIDC profile claims in your ID tokens.<p>Actually no, that&#x27;s on the spec for not enforcing they&#x27;re in the ID token, and only must be available in the userinfo endpoint.

A disconnect I often wonder about:<p>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.<p>People implementing APIs: return a 200 response for everything, even an error ¯\_(ツ)_&#x2F;¯<p>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?<p>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.<p>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.

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.

Another one: Microsoft azure not wanting to send you an access token in the &quot;Token Endpoint&quot; unless you inject the client_id in the scope ....

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&#x27;t yet such a certification for oauth, although the oidc federation certifies and lists a bunch of them: <a href="https:&#x2F;&#x2F;openid.net&#x2F;developers&#x2F;certified-openid-connect-implementations&#x2F;" rel="nofollow">https:&#x2F;&#x2F;openid.net&#x2F;developers&#x2F;certified-openid-connect-imple...</a> (I maintain one of them). Which is the next best thing.

Giving a talk about this today. Biggest problem imho is the fact there were over 33 revisions, and now over 20 RFCs related to oauth. Developing to spec is hard when you don’t realize how big the spec is.

<a href="https:&#x2F;&#x2F;gist.github.com&#x2F;nckroy&#x2F;dd2d4dfc86f7d13045ad715377b6a48f" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;nckroy&#x2F;dd2d4dfc86f7d13045ad715377b6a...</a>

Fat chance of them changing this now, Hyrum’s law says someone is depending on this.<p><a href="https:&#x2F;&#x2F;www.hyrumslaw.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hyrumslaw.com&#x2F;</a>

If you consider the newest rfc9068: <a href="https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;html&#x2F;rfc9068" rel="nofollow">https:&#x2F;&#x2F;datatracker.ietf.org&#x2F;doc&#x2F;html&#x2F;rfc9068</a> for JWT profiled Access Token, the list of discrepancies is even longer.

&gt; Your server, for whatever fucking reason, returns a string for the token expiration.<p>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&#x27;t understand the basis for the rule they are following.

I wish OAuth said something about what to do when someone signs up with email&#x2F;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.

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

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

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.

What&#x27;s the general sentiment, is the basic auth not done by some because it&#x27;s considered weak security?

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

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

Discord also doesn&#x27;t work with Firebase OIDC.

Had such a good laugh with this :D

Thank you.

You had me until &quot;Please support HTTP basic auth for client authentication&quot;.<p>OAuth 2.1 draft spec emphasizes that basic auth is no longer preferred. I read that to mean: MAY, or perhaps even SHOULD NOT.

Always read the receipt.<p>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