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…
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.
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 bothid_token and code). As an example:
GET https://id.twitch.tv/oauth2/authorize?
client_id=<your client id>&
scope=openid+<your scope>+<another scope>&
response_type=id_token+code
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>&
scope=openid
response_type=code
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?
1.A
GET /authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile%20email
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj HTTP/1.1
Host: server.example.com
HTTP/1.1 302 Found
Location: https://client.example.org/cb?
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=af0ifjsldkj
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.
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!