Quick post today. Of course, when implementing Azure AD authentication, you should use the Microsoft Authentication Library. Some times, however, you have platform limitations that limits you to implement OpenID Connect “from scratch”. So one of my customers did, but we found the ID Token to be signed by a key with key identifier (kid) that we could not find in the jwks urls found in the OpenID Connect metadata. However, I found it eventually and here is how.
When creating an application, such as when following this blogpost about roles in the ID Token and then running the below PowerShell, the ID Token posted to localhost is signed, and the key identifier “kid” is provided:
$clientid = "dd54e8b7-8c69-435a-a460-e7041f98ee30"
$tenant = "e88da32e-db23-4b1e-af95-f808ac863371"
$redirectUrl = "https://localhost:4000/"
# Simply run the following
Read-host "Click enter to put the authorize url on your clipboard" -Verbose
$authorizeUrl = "https://login.microsoftonline.com/$tenant/oauth2/authorize?client_id=$clientid&response_type=code+id_token&redirect_uri=$redirectUrl&response_mode=form_post&nonce=asdokasokdojfoejf"
$authorizeUrl | Set-Clipboard
Write-Verbose "Url copied, please open a browser and paste the url and sign in" -Verbose
What i thought was that this KID is found in jwks url from the OpenID Connect metadata document of the tenant – https://login.microsoftonline.com/e88da32e-db23-4b1e-af95-f808ac863371/.well-known/openid-configuration. However, you will find that the jwks_url of the tenant is actually the same as the common endpoint – https://login.microsoftonline.com/common/discovery/keys. And of course, if all tenants in the world would share the same keys, that would not be good for security.
Where i was wrong was that the metadata document of the tenant is not where to look for the jwks uri, actually, you should look in add a parameter appid to get https://login.microsoftonline.com/e88da32e-db23-4b1e-af95-f808ac863371/.well-known/openid-configuration?appid=dd54e8b7-8c69-435a-a460-e7041f98ee30. Checking out this metadata actually shows you that the jwks url you need is https://login.microsoftonline.com/e88da32e-db23-4b1e-af95-f808ac863371/discovery/keys?appid=dd54e8b7-8c69-435a-a460-e7041f98ee30 , where the first guid is the tenant ID, while the second guid is the application id / client id of the application.
Hope this helps someone 🙂
Good Workaround! 
But how did you figure that out? Could you provide some link to documentation?
In the sentence below the code example here: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc#sample-response
Not really too well documented, though I guess this is why using SDKs are recommended.