I do not quite understand the goal - what would you like the well-known location to resolve to instead?
The .well-known system (RFC 5785) is used for providing host metadata by hosting it in a pre-defined location, and (as far as I know) is the only IETF-encouraged mechanism for statically defining the location of content or an API over HTTP. The RFC and OpenID Foundation input document differ in that the OpenID variant did not construct the well-known location in the expected manner (e.g. with all information under /.well-known/openid-configuration ) Since RFC8414 defines OAuth server metadata using the well-known system, the metadata is going to be specific to the host - in the second case provided, it will be resolved by looking at a static location on https://sampletenant.api.asgardeo.io <https://sampletenant.api.asgardeo.io/> . That is a function of the metadata being for a particular host, and not the mechanism to distinguish path components. Unfortunately, changing this to resolve .e.g by looking at each valid parent domain would change security properties. Note however that there is no reason that https://api.asgardeo.io/t/sampletenant couldn’t be used as the issuer identifier, get resolved via a .well-known on api.asgardeo.io <http://api.asgardeo.io/>, but point entirely to endpoints on sampeltenant.api.asgardeo.io <http://sampeltenant.api.asgardeo.io/>. I however do not understand the reasoning that the well-known data couldn’t be hosted on the subdomain directly if endpoints are also on the subdomain. -DW > On Jul 31, 2025, at 1:05 AM, Pavindu Lakshan <[email protected]> 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 > <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 > <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 -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
