3 ms·
And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll t
by derefr 4y ago
And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll take your email address and check the DNS record of the domain to figure out who your IdP is, and then send you there."
Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all those implementation-dependent details of how you're supposed to talk to an OAuth IdP.
Compare/contrast: SAML. SAML binding a webapp to an arbitrary IdPs just by punching in the IdP's SAML config endpoint URL? Works perfectly.
- pas 4y agoOIDC Discovery to the rescue! https://swagger.io/docs/specification/authentication/openid-connect-discovery/ https://swagger.io/docs/specification/authentication/openid-...
- pl4nty 4y agoAs much as I love OIDC, it still doesn't handle out-of-band client registration
- codebje 4y agohttps://datatracker.ietf.org/doc/rfc7591/ https://datatracker.ietf.org/doc/rfc7591/ The only reason an authorisation server would support dynamic client registration, however, is because it's meant to be pluggable as the back-end for an API integration suite like Kong Enterprise. The solutions that are one big well-known IdP have no reason to want it, so Google Auth, Amazon Cognito, and similar all don't support it. The solutions that are aimed at letting organisations be an IdP do have reason to offer it: it makes being an IdP easier, because you can stand up a client registration service without using vendor-specific interfaces. No-one who operates an IdP wants arbitrary, uncontrolled public client registration. It'll get abused directly, and it'll enable further abuse of the systems the IdP is meant to protect.
- codebje 4y agoThere's a single URL for OIDC IdPs too. It's not supported in every web app for the same reason SAML isn't: it's a two-way exchange to set up, not a one-way exchange. In OIDC (OAuth 2) you need to register a client first. In SAML you need to register a Service Provider first. Only after you've done those steps will you be able to plug the magic configuration in and have it work. SAML is too limited to compete with OIDC/OAuth2 on the web, but it's got some advantages for enterprise authentication, so it won't be going anywhere.
- krinchan 4y agoYes because embedded XMLDsig is great! I've never seen a SAML implementation that worked reliably across IDPs outside of Java, honestly.