Hi David, I do not quite understand the goal - what would you like the well-known > location to resolve to instead?
Apologies for not clarifying the end goal. Can we relax this restriction so that the .well-known part will be suffixed to the end of the authorization server URL, so that the AS metadata URL of AS https://api.asgardeo.io/t/sampletenant/oauth2/token would be https://api.asgardeo.io/t/sampletenant/oauth2/token/.well-known/oauth-authorization-server ? 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 . 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, but point > entirely to endpoints on 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. Quoting from the AS metadata spec, Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of ".well-known" is for supporting multiple issuers per host; unlike its use in RFC 5785 <https://datatracker.ietf.org/doc/html/rfc5785> [RFC5785 <https://datatracker.ietf.org/doc/html/rfc5785>], it does not provide general information about the host. If the defined path component handling mechanism is to support multiple issuers per host, hosting the .well-known on subdomain would violate the specification, wouldn't it? On Thu, Jul 31, 2025 at 1:22 PM David Waite <david= 40alkaline-solutions....@dmarc.ietf.org> wrote: > 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 . 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, but point > entirely to endpoints on 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 <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 > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
