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.
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.
> 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.
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".
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.
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.
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
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.
Agreed, I have seen some sites check the email used and link the account instead of creating a new one. I much prefer this.
only works with email validation. Sadly some providers don’t do this (not even Microsoft azure ad in some cases…)
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.
1password's browser extension attempts to record this for you.
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.
> This isn’t about being spec-compliant anymore. I need to know the thought process behind this decision. And also please fix it.
Using php or something and not paying attention? Read the value from database, by default php casts all colum types to string in retrieval, except for a null value, or if you tell it to try to match column types to php types.
My guess is the JSON serializer uses strings for int64s to avoid loss of precision.
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.
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?
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1
It's in Section 5, actually. That one is for the implicit-grant flow, so the fields are URL-encoded and appended to the redirect URI's query fragment.
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".
Which are buggy as hell
For open standards like this, it would really help if there was an official, readily available test suite anyone could run.
Sure there's the spec, but it's a lot to keep track of for the intern that inevitably ends up implementing such things.
Having a test suite you to verify you didn't mess up would be very useful.
Like this: https://openid.net/certification/about-conformance-suite/
I only dabbled with OpenID as an end-user, but I really really liked the fact that I could tie my identity to a domain I owned, and then temporarily delegate the credential-mechanics to another entity.
In this way, the identity was durable and portable, at least as long as one maintains control over the URL.
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.
Thank you.
What's the general sentiment, is the basic auth not done by some because it's considered weak security?
It requires the first party to the credential validation, for one thing. That means you have to have a separate account for every service, or expose your password for your shared account to those services.
AFAIK. YMMV.
You also have to store the plaintext password Somewhere. Same problem with DIGEST.
Where did you get this from? You know how passwords are matched right?
What? Why?
Discord also doesn't work with Firebase OIDC.
Been considering a switch to stalw.art for my personal mail server since it can also act as an IdP. Wonder how this author would it.
If you get this command to output anything during install, please let me know: "docker logs stalwart-mail"
Have reached out on multiple channels and only crickets.
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.