Hacker News Reader

Comment by paulddraper | Hacker News Reader

> 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?

View on HN

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 point is that if you require

  /.well-known/openid-configuration

to tell your the OAuth URLs, why not just require the OAuth URLs to be

  /.well-known/openid/authorize
  /.well-known/openid/token

> by not requiring the creation / new routing of those endpoints, OIDC adoption is easier on the OIDC provider side.

Redirects exist though. We already have the technology, we already have the protocols, we're just inventing more stuff that we already have.

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

Reply on news.ycombinator.com