Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…
On second glance, the validator is dictated by the domain owner so this falls into the "in case it's the latter, then this doesn't have as big an impact I guess" category.
I'll put this on the backlog of things to implement if I'm incredibly bored and want to weaken the security of my infrastructure.
Not everyone uses an email provider that is also also an OIDC provider.
But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?
One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain.
Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite difficult.
Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you…
I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!) The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found…
I didn't say it was impossible, just impractical and that is why majority of services that use SSO only support google, apple, twitter or facebook. You write the code specific to these few providers once and are done with it for good. There is little reason to invest time and money for adding generic support for other providers. It's just the way it is. If OIDC protocol would get streamlined a bit, we could easily have universal support. But then again, these big providers would likely be stuck in the current version and not bother adjusting to the new, simpler version, if it would come to be.
What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email. Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?
The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication. If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email a…
Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.
With DCR (dynamic client registration) you can have an unlimited number of providers. Basically, just query the well-known endpoint and then use regular OAuth with a random secret. There's also a proposal to add stateless ephemeral clients.
DCR is cool, but I haven't seen anyone roll it out. I know it has to be enabled per-tenant in Okta and Azure (which nobody does), and I don't think Google Workspace supports it at all yet. It's a shame that OIDC spent so long and got so much market-share tied to OAuth client secrets, especially since classic OpenID had no such configuration step.
DCR is now being pushed by AI companies, using the MCP protocol that basically requires DCR.
So it might get some traction, and finally break the monopoly of "Login With Google" buttons.
Skimming that I'm thinking yes, sure, why not, but this repo is missing useful context. Who are you, authors? Why should I bother learning this protocol? Is anyone using or going to use this? If it's new, has it been shopped around at conferences? Any related research?
And specifically Sam goto (Google, fedcm) and Dick Hardt (hello, oauth2 spec writer).
This was originally thought up a couple (5-6) years ago along side fedcm and privacy sandbox, but before SD-jwt was full baked, so it wasn't as clean. The use of SD-jwt is much better for privacy.
OIDC is usually limited to a small selection of providers.
Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you…
Pkce is trivially easy to announce support for, you put it in the issuer metadata.
DCR is cool, but I haven't seen anyone roll it out. I know it has to be enabled per-tenant in Okta and Azure (which nobody does), and I don't think Google Workspace supports it at all yet. It's a shame that OIDC spent so long and got so much market-share tied to OAuth client secrets, especially since classic OpenID had no such configuration step.
DCR is now being pushed by AI companies, using the MCP protocol that basically requires DCR. So it might get some traction, and finally break the monopoly of "Login With Google" buttons.
This is because the MCP folks focus almost entirely on the client developer experience at the expense of implementability
CIMD is a bit better and will supplant DCR, but overall there's yet to be a good flow here that supports management in enterprise use cases.