Issue with "id_token" check in "oauthCallback" flow

[aidenfoxx]

Hello. In 92ffee5 a check was added that would reject oauthCallback requests if they contain an id_token. This has caused an issues with the OAuth flow in Directus where openid-client is used.

directus/directus#11048

The issue is that Facebook always returns "id_token" in its OAuth flow. There is an alternate OpenID flow but it does not support the "code" authentication type.

We can't handle this nicely since we don't know if the response contains an "id_token" before triggering an oauthCallback, but calling oauthCallback triggers an exception. Obviously we could handle the exception and trigger callback, but it personally feels better to revert the "id_token" check as I don't believe it adds value.

I would be curious to hear what you think?

[panva]

Are you saying you don't know what type of authentication request you triggered? Because you either trigger an openid connect flow (regardless of what response_type) with the openid scope or you don't. Meaning on callback you either use callback or oauthCallback. You always know what you expect from the callback upfront.

Basically, if you run into the check the fix added, you're using the client wrong. The value is there, if you do trigger openid requests you ought to take advantage of it, routing those responses to oauthCallback is wrong, unintended, and removes the many checks openid connect puts in place.

[panva]

I've verified with the OP and their scope is "email public_profile". So Facebook is always sending back an "id_token" regardless.

I have just checked with a fresh Facebook implementation, it is not until I add the openid scope to the authorization request that an ID token is returned by the token_endpoint. That's the behaviour as I expect it. Without the openid scope I get no ID Token and I can use the oauthCallback method.

[panva]

Also, when i add the openid scope I can use regular callback() just fine, the only caveat is that the Issuer instance needs to be constructed manually since their well-known does not list the token_endpoint.

[panva]

Bottom line, facebook did not magically start adding ID Tokens to non-openid flows, your issue's OP is somehow requesting the "openid" scope which makes callback the appropriate method to use instead of oauthCallback.

This has been quite time consuming, it has however reassured me that this validation should stay in place to avoid 🦶🔫.

[aidenfoxx]

Hm... Sincere apologies for wasting your time then! I was fairly certain I'd gotten an "id_token" back from FB in the past without "openid" in the scope, and the OP confirmed my bias. But I guess there is something wrong on their side. Never the less, I will investigate this over the weekend and I'll be sure to remove the hacky TokenSet.prototype.claims() fallback in the oauth provider.

Thanks for all your assistance!

[aidenfoxx]

@panva I debugged the issue and it appears both parties were correct. It is possible for Facebook to always return an "id_token" regardless of the defined "scope". This only occurs if the user has authorized the app with "openid" in their scope in the past. From that point Facebook always considers the login to be "openid".

To solve this all I had to do was revoke access in my Facebook account and then everything works as you describe.