简体   繁体   中英

Bad id_token issuer when trying to authenticate with Battle.net OIDC with Cognito

I've spent the last couple days trying to set up Cognito to use Battle.net OIDC. I believe I am most of the way there. I can see using the cognito hosted UI that it authenticates correctly but then fails, presumably trying to retrieve the token.

The first request to cognito hosted UI:

https://<removed>.auth.us-west-2.amazoncognito.com/oauth2/authorize?identity_provider=Blizzard&redirect_uri=https://<my-site-oauth-handler-removed>/oauth&response_type=CODE&client_id=<removed>&scope=openid

Then the next request is to Battle.net OIDC as expected:

https://us.battle.net/oauth/authorize?client_id=<removed>&redirect_uri=https%3A%2F%2F<removed>.auth.us-west-2.amazoncognito.com%2Foauth2%2Fidpresponse&scope=openid&response_type=code&state=<removed>

Then the code is passed onto the cognito idpresponse:

https://<removed>.auth.us-west-2.amazoncognito.com/oauth2/idpresponse?code=<removed>&state=<removed>

At this point, if my understanding is correct cognito should try to hit the battle.net /oath/token endpoint and then return the id_token and access_token to my redirect_url. It is at the point cognito instead returns an error to my url:

https://<my-site-oauth-handler-removed>/oauth?error_description=Bad+id_token+issuer+oauth.battle.net&error=invalid_request

Judging by the lack of documentation for Battle.net OIDC I may be one of a handful trying to use the battle.net OIDC with Cognito. It very well could be a bug with their implementation but I'm trying not to jump to that conclusion.

My best guess right now is that I haven't configured Cognito correctly to make the token POST request. It needs to use Basic Authentication with the clientid:password but I can't verify if it's doing that correctly or not since its abstracted away.

Anyway, when I make the request through my app (using amplify to open the hosted UI) it does return but with the following:

[ERROR] 51:05.25 OAuth - Error handling auth response. Error: Bad+id_token+issuer+oauth.battle.net
    at OAuth.<anonymous> (OAuth.js:202)
    at step (OAuth.js:52)
    at Object.next (OAuth.js:33)
    at OAuth.js:27
    at tryCallTwo (core.js:45)
    at doResolve (core.js:200)
    at new Promise (core.js:66)
    at __awaiter (OAuth.js:23)
    at OAuth.handleAuthResponse (OAuth.js:181)
    at AuthClass.<anonymous> (Auth.js:1632)

Here is all my relevant Cognito configuration:

OIDC Provider:

  • Provider Name: Blizzard
  • Client ID: [removed]
  • Client Secret: [removed]
  • Attributes request method: POST
  • Authorize scope: openid
  • Issuer: https://us.battle.net/oauth

App Client:

  • Name: [removed]
  • App client id: [removed]
  • App client secret: (no secret key)

App Client Settings:

  • Enabled Identity Providers: Blizzard
  • Callback URLs: https://[removed]/oauth
  • Sign out URLs: https://[removed]/oauth

  • Allowed OAuth Flows:

    • Authorization code grant
    • Implicit grant
  • Allowed OAuth Scopes
    • email
    • openid
    • aws.cognito.signin.user.admin
    • profile
  • (I've tried every variation of these and it doesn't appear to change the outcome)

Federated Identity:

  • Authentication providers
    • OpenID
      • us.battle.net/oauth

IAM Identity Providers:

  • Provider Name: us.battle.net/oauth
  • Provider Type: OIDC
  • Provider URL: us.battle.net/oauth
  • CA Thumbprint: [removed]
  • Audience: [my battle.net client id]

I have exhausted my own resources and am asking for any guidance with this.

Thanks!

This was caused by Blizzard issuing their tokens from their well-known endpoints but setting the iss field to oauth.battle.net which caused Cognito (or any other token validation) to fail hence the error message

Bad+id_token+issuer+oauth.battle.net

I brought this up to their API team in Discord and they are releasing a fix on November 25th according to an email send to developers.

Dear community developer,

Earlier this year, we introduced a new OAuth discovery endpoint which implements the OpenID Connect discovery specification. We would like to deploy a change to 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 JSON response. This would be a potential breaking change to some of the OAuth OIDC clients but it conforms to the OpenID connect specification: https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier

Your OAuth client application was identified as one that could be affected by this change.

We are planning to release this change on November 25, 2019.

Here are the steps that you can take to ensure your OpenID Connect client will continue working after the change:

Navigate to one of the well-known configuration endpoints below which corresponds to the region where your client application operates and check the "issuer" field.

If the issuer field matches the configured issuer for your OAuth OIDC client then your client is compatible and you are already compliant and do not need to make any changes.

If the issuer field from the well-known configuration endpoint is different than the issuer set in your client configuration, please change the issuer to match the well-known configuration endpoint.

If your client supports the OpenID discovery endpoint standard, you can configure it to read all necessary settings from the well-known configuration endpoint. Your OAuth client should self-configure.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM