> 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.
The way I usually see it implemented is that all of the subdomains resolve to a load balancer or whatever is pointing at your multi-tenant service. Your service then uses the subdomain value in the Host header to return the appropriate AS metadata for that issuer, dynamically. (I think this is more or less what other folks have been hinting at) An added advantage here is if your customer switches to a vanity domain, the internal tenant name is completely hidden. If you have the tenant name in the path then you're stuck with it. Matt MacAdam On Thu, Jul 31, 2025 at 1:39 AM <[email protected]> wrote: > Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..."Today's Topics: > > 1. Clarification on constructing Authorization Server Metadata URL when > the issuer URL has a path component > (Pavindu Lakshan) > 2. Re: Clarification on constructing Authorization Server Metadata URL > when the issuer URL has a path component > (David Waite) > 3. Re: Clarification on constructing Authorization Server Metadata URL > when the issuer URL has a path component > (Pavindu Lakshan) > > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
