OIDC Auth Flow won't return ID Token

I am following the “OIDC Authorization Code Flow” section found here:

So, I make my initial GET call to:
Using “response_type” as “code” as specified to do so.

I then use this code as part of my POST call to:

However the response contains ONLY:
access_token, expires_in, response_token, scope

When it should also contain an id_token.

I then realised I missed out the bit that said my initial GET call should “This must include the openid scope.”

Once I add the openid scope and then do that initial GET call, the response I then get back is as follows:
{“status”:400,“message”:“invalid response type: ‘id_token’ required for ‘openid’ scope”}

Then when I add id_token to the response type, be it before or after code, it starts to redirect to my callback URI placing the id_token as a URI Fragment which ISN’T obviously what I want…



I also have this issue. So I’m not currently using id.twitch for OIDC

Thanks for the response.
Can you elaborate on what you mean by using id.twitch as an alternative?


Do the reverse of the id.twitch migration guide:

So go back to the old Kraken APIs for now? :slight_smile:

For OIDC? Yes. I flagged this the other day when I migrated to id.twitch then rolled back.

So hopefully ti’s a known issue with a fix on the way

Bad news.
I’m now on the old kraken APIs and getting the same problem.

I’ve even tried with openid added to the scope and a response type of “code id_token” once again takes the URL fragment route.

The main difference is that openid now seems to work without returning the:
{“status”:400,“message”:“invalid response type: ‘id_token’ required for ‘openid’ scope”}
error however I still get back absolutely no ID Token.

Hey there,

If you’d like to use the authorization code flow and also receive an ID token, please make sure to include the openid scope (you can include any additional scopes you need, just make sure openid is one of them) and make sure to include id_token in the response type (this means you’ll pass both id_token and code). As an example:

GET https://id.twitch.tv/oauth2/authorize?
  client_id=<your client id>&
  scope=openid+<your scope>+<another scope>&

Unfortunately, the ID token must be included in the redirect URI as a URL fragment instead of the query string per the OIDC spec: http://openid.net/specs/openid-connect-core-1_0.html#OAuth.Responses.

Also, if you’re using https://id.twitch.tv/oauth2/authorize to initiate the OAuth flow, please remember the corresponding token exchange endpoint is https://id.twitch.tv/oauth2/token, not https://api.twitch.tv/api/oauth2/token


The docs

Doesn’t match with this then.

Also a bunch of the examples there are just wrong/needs a rewrite.

This change on id.twitch makes using the Twitch API to perform a website login “interesting” due to the helix rate limits. Which was why I switched to OIDC anyway, as that gives the Users ID without a Helix API look up. And having to fetch a URI fragment for login isn’t fun

A call to:

GET https://id.twitch.tv/oauth2/authorize?
 client_id=<your client id>&

Results in

{“status”:400,“message”:“invalid response type: ‘id_token’ required for ‘openid’ scope”}

Which disagrees with the docs. And appears to be valid in the OIDC spec?


  GET /authorize?
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com

  HTTP/1.1 302 Found
  Location: https://client.example.org/cb?

That allows OpenID via response_type code doesn’t it? Then code exchange the code and get the ID Token. Just like https://api.twitch.tv/kraken/oauth2/ yes?

Appreciate the response and what you are saying is essentially what I was experiencing so you’re spot on. Thanks for the explanations regarding the endpoints too.

However, it is worth noting that while you say the ID token can only be retrieved alongside the code as a URL fragment, the API documentations say otherwise which is where the whole confusion has stemmed from.

Barry seems to explain some of the issues with the lack of matching documentation for now.


Same issue here, we should be able to use ‘code’ response_type standalone, like any other implementation…

Unfortunately, we’re aware of some inconsistencies in the documentation and we are in the process of revising its inaccuracies.

And I believe you’re correct that the code response type should be supported per the OIDC spec. Stay tuned for updates to our documentation and to our APIs to support these fixes!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.