Remix.run Logo
eschatology 8 hours ago

Not one of them links to the actual well-known resource, only pdf specifications. And several I picked randomly leads to dead ends.

Here's one I could find: https://accounts.google.com/.well-known/openid-configuration

But how does one even find this?

masklinn 8 hours ago | parent [-]

well-known is for programmatic access, it either namespaces something you’re told to look for (e.g. various types of domain markers) or it lets you discover a feature / endpoint.

In the latter case you just probe, for instance if you’re a password manager and you have a password for site A you hit A/.well-known/change-password and if they returns something you can surface a change password link to your user.

The one you found is for OIDC provider discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#P...) so someone tells you they want to log in via Google, you hit that endpoint, and it lets you setup Google as an oidc provider rather without needing to hard-code providers. Even if you just want to support Google as a provider, you hit that and you get the entire configuration rather than have to hunt down the same information in the docs.

eschatology 7 hours ago | parent [-]

Thank you, that it is part of OIDC provider discovery spec explains a lot.

That said, I still find it very bizzare that it's so hard to find a tangible example to see how it is in practice.

The rfc has none. Another spec including the use of it has none. In the end only completed service provider/implementers show it.

Before programmatic access happens, it needs to be written by a human. Yet the whole thing feels so human-unfriendly.

Perhaps I am biased robots.txt sets a high bar on how easy it is to find and work with?

masklinn 7 hours ago | parent [-]

What RFC? The oidc discovery spec has an example, and for change-password it’s just a redirect. RFC 8615 is about the existence and management of the .well-know namespace, so examples don’t really make sense.

hparadiz 6 hours ago | parent [-]

A JWKS is defined at /.well-known/jwks.json

It's a JSON array of public keys which you can use to validate a JWT which is what an OIDC token is.

Making it an array means you can rotate keys whenever but the validator is typically caching the public keys.

https://www.hanko.io/blog/understanding-jwks

Actually... found it https://datatracker.ietf.org/doc/html/rfc6749

And here's a PHP implementation that is perfect. https://github.com/thephpleague/oauth2-client