10 ms·

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

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 3mo ago
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 3mo ago
  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 https://www.hanko.io/blog/understanding-jwks Actually... found it https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749 And here's a PHP implementation that is perfect. https://github.com/thephpleague/oauth2-client https://github.com/thephpleague/oauth2-client
amiga386 3mo ago
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 3mo ago

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 3mo ago
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 https://www.hanko.io/blog/understanding-jwks Actually... found it https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749 And here's a PHP implementation that is perfect. https://github.com/thephpleague/oauth2-client https://github.com/thephpleague/oauth2-client

amiga386 3mo ago

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.