[eschatology]

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?

[amiga386]

Pretty much all service discovery should work this way:

1. User enters hostname (or comes in from a QR code or TXT record or whatevs)

2. Client requests GET https://<hostname>/.well-known/<servicename>

3. This either redirects to the canonical base path of the service, which then can be queried itself for instances, or it directly returns a JSON/XML/whatever array of instances of the service on this server, and their respective base paths

This is a lot better than assuming the service must be the document root (forcing service discrimination into the hostname) or assuming it can always have /<servicename>/ as a base path.

[masklinn]

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]

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