Battle net oauth id_tokens are signed with incorrect iss

API Discussion
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.

1 Like
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: Final: OpenID Connect Discovery 1.0 incorporating errata set 1

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: Final: OpenID Connect Core 1.0 incorporating errata set 1). Until we get this fixed, maybe there are solutions for using Cognito with Google’s API that would also apply here?

3

On November 25, 2019, we have a fix going out in which we are changing the issuer field iss of the id_token during the OpenID authorization flow from oauth.battle.net to the issuer that is returned by the well-known configuration endpoint of the JSON response. As you mentioned, this will now conform to the OpenID connect specification: Final: OpenID Connect Core 1.0 incorporating errata set 1