Le jeu. 31 juil. 2025, 10:38, Pavindu Lakshan <pavindulaks...@gmail.com> a écrit :
> 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 > ? > Are you really unable to serve a .well-known/oauth-authorization-server/t/sampletenant/oauth2/token resource? IOW, why do you want/need that change? > 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? > Why? A subdomain is a different host. > 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 >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
