> So they generalize the discovery approach from OpenID Connect specification into RFC8414 that adds a new metadata route under .well-known subpath.
That route contains URLs of the authorization and token endpoints, supported token authentications, OpenID user URL, etc.
“Yo I heard you like URLs so I made URLs for your URLs.”
But seriously…if you’re going to have fixed URLs, why not just have fixed URLs for these endpoints? What does the indirection get you?
The indirection gets you simplicity during integration, as in the optimal case the consumer only has to point to a single URL than to a handful, and rest of the URLs can be auto-discovered from there.
Also if you look at the typical endpoints you see listed there you'll find that they are usually pre-existing oauth2 endpoints that predate OIDC, so by not requiring the creation / new routing of those endpoints, OIDC adoption is easier on the OIDC provider side.
And lastly you'll need the metadata endpoint anyway for all the non-URL data that is exposed by that endpoint.
my guess the idea and intension of .well-known was good, so generic end-user libraries can be implement ... the reality is ugly and generate lot of man hours for cyberops consultancies
“Yo I heard you like URLs so I made URLs for your URLs.”
But seriously…if you’re going to have fixed URLs, why not just have fixed URLs for these endpoints? What does the indirection get you?