Battle net oauth id_tokens are signed with incorrect iss


#1

After a full week of trying to debug a very vague Bad+id_token+issuer+oauth.battle.net I finally found where that issuer URL is coming from.

If you decode the id_token payload (without the jose or signature) you get something like:

{
  "at_hash":"<removed>",
   "sub":"<removed>",
   "aud":"<removed>",
   "azp":"<removed>",
   "iss":`oauth.battle.net`,
   "exp":1569748660,
   "iat":1569662570,
   "jti":"<removed>"
}

WHY IS iss: oauth.battle.net!?

This will cause any process doing a correct validation of the issuer to fail since the correct issuer should be https://{region}.battle.net/oauth since that is where the well-known configuration file is found.

With Cognito (and any oauth client doing a correct validation of the token), users are required to enter an endpoint with https:// prefix that matches the iss that the id_tokens are signed with.

Would really appreciate a dev response on this, I’ve been hitting my head against the wall literally all week and in the process gained a DEEP understanding of oauth.


Request for assistance - Blizzard OIDC with Cognito
#2

Hey Ryan! For posterity, I’m copying this answer from the unofficial Discord.

Thanks for reporting this! We have a bug in internally to track this. Until we release a hotfix, if possible, you could attempt to disable the issuer validation on your end. According to the Discovery endpoint specification, the issuer validation step is optional. See here: https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

For full visibility, what’s going on here is that there’s a small contradiction in the official OpenID Connect specifications that causes this issue, and you happen to be caught in it. Interestingly enough, some other providers also have this issue (for example, Google, information here: https://openid.net/specs/openid-connect-core-1_0.html#GoogleIss). Until we get this fixed, maybe there are solutions for using Cognito with Google’s API that would also apply here?