Pavindu, The OpenID Foundation and the IETF differ on what a "well-known" path means...
What we do for CUPS is to first try appending the well-known paths to the issuer URL, so an issuer/AS URL of "https://oauth.example.com/mumble"; would yield "https://oauth.example.com/mumble/.well-known/openid-configuration"; and "https://oauth.example.com/mumble/.well-known/oauth-authorization-server";. If those don't work we try again from the root (where they *should* be), yielding "https://oauth.example.com/.well-known/openid-configuration"; and "https://oauth.example.com/.well-known/oauth-authorization-server";. This, along with a bunch of other conditional code, seems to allow us to interoperate with the plethora of OAuth/OIDC implementations out there... > On Jul 31, 2025, at 8:05 AM, Pavindu Lakshan <pavindulaks...@gmail.com> wrote: > > Hi all, > The OAuth Authorization Server Metadata specification [1] states that when > the authorization server URL includes a path component, the metadata endpoint > should be constructed by removing that path, appending > /.well-known/oauth-authorization-server, and then adding the original path > component to the end. > For example, if the issuer URL is > https://api.asgardeo.io/t/sampletenant/oauth2/token, the correct metadata URL > (according to the current spec) would be: > https://api.asgardeo.io/.well-known/oauth-authorization-server/t/sampletenant/oauth2/token > This approach seems to be based on the reasoning that a single authorization > server may support multiple tenants or issuers, and that placing .well-known > at the AS root and appending the remaining path better reflects that > hierarchical structure [2]. > However, this reasoning doesn’t quite apply when the tenant is represented > using a subdomain. > For instance, if the issuer is https://sampletenant.api.asgardeo.io, since it > lacks a path component, the metadata URL would simply become: > https://sampletenant.api.asgardeo.io/.well-known/oauth-authorization-server > — even though https://sampletenant.api.asgardeo.io may not truly represent > the AS root, but rather another issuer defined by the IdP. > Given this, would it be possible to revisit the restriction around path > component handling for constructing the AS metadata URL? > [1] https://datatracker.ietf.org/doc/html/rfc8414 > [2] https://datatracker.ietf.org/doc/html/rfc8414#section-3.1 > > Best regards > Pavindu > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org ________________________ Michael Sweet _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
