7 ms·

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: ht

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 https://accounts.google.com/.well-known/openid-configuration But how does one even find this?

masklinn 3mo ago
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#ProviderConfig 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 3mo ago
  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

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#ProviderConfig 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 3mo ago
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.