Auth0 Home Blog Docs

Custom domains and "iss" claim in tokens

custom-domain
jwt-validation

#1

The company I work for just switched to custom domains for all our authentication logic and that created a bunch of issues that we are now trying to resolve. As we use multi-tenant approach and will end up with roughly 10+ tenants in the end we need a sensible solution to maintain tenants, rules and hooks up. The problems that we are facing are:
Q1: Hooks are currently not supported by the GitHub Extension - is there a roadmap or estimated date?
Q2: The “iss” claim in the tokens - one of the steps to verify the issuer is to “check if the issuer can be trusted” - this normally happens by simply providing the list of “trusted” domains but with “custom domains” in the twist this makes the list of domains twice as big… And also requires every micro-service that we have in place (currently about 5) to have a list of these domains maintained manually. This obviously is not ideal so we devised a way to validate the issuer by the means of “signing” the issuer claim at a trusted party (Auth0) with a private key and then verifying that signature in each micro-service using a public key. Unfortunately we’ve hit yet another problem - the “contexts” available in “Rules” as well as “Hooks” are different and although Rules expose “context.request.hostname” that we can use to validate the issuer field as it will be directly related to “iss” claim, in Hooks however - the only thing we can use is the “context.webtask.body.client.tenant” which doesn’t have to directly relate to “iss” claim found in the token… In fact the “iss” claim is always set to the “domain” used to request the token which makes sense but inability to access either the “issuer”, or domain in both contexts is somehow annoying… Has someone come up with a way to “verify” the “iss” claim without the hardcoded list?
Q3: Why does the “iss” contain a trailing slash?
I think it would make sense for Auth0 to expose the “issuer” field in both contexts just as they will appear in the token to begin with as well as the “custom” or “original” domain the request belongs to… Can we hope for that Auth0?