Role of supports_token_authentication on providers?

[joonhyungshin]

Hi,

I've recently been interested in the API feature that will be released sooner or later. I plan to use allauth as the backend for my web/mobile app, and I hope to integrate social account providers for authentication.

As far as I understood, for apps running in a non-browser context, the only way the client can authenticate via 3rd party is through the provider token endpoint. It seems like only the providers with supports_token_authentication flag set are supported (source). So currently only Apple, Facebook, and Google providers are supported (which doesn't fulfill my needs unfortunately).

Now the question is, what supports_token_authentication is for. The ProviderTokenInput validator looks for verify_token() method, so I suppose the flag is set for providers that have an 'official way' of verifying the token. For instance, Apple and Google provide id_token, and Facebook has the debug_token/ endpoint.

But why is the userinfo/ endpoint not counted as an 'official way' of verifying the access token? For example, we can just call the userinfo/ endpoint, terminates the flow if it fails, or constructs the sociallogin instance if it succeeds. Success means the access token is valid. After all, unless id_token is provided, we should call this API to pull user profiles, just like the Facebook provider does. This way, virtually all OAuth2 providers can be used for provider token authentication. But if we can do this supports_token_authentication seems unnecessary, so I must be missing something.

I am relatively new to authentication, so I have limited understanding of OAuth2 or OIDC standards. Please correct me if I am wrong. Thanks in advance!

[pennersr]

There are some caveats to accepting external access tokens (tokens that allauth didn't obtain on its own) for authentication purposes. If users have social accounts on your site, and some other site, it should not be possible for that other site to harvest access tokens, and then pass these along to your site in order to authenticate (hijack) the identities of other users. So, checks need to be in place to check if the access token really belongs to the OAuth client of your site, and not the other site. Therefore, we cannot just opt in all providers to token authentication as we need to check this on a case by case basis.

[joonhyungshin]

Thank you! I think I got it. Perhaps those without token verification support should still rely on browser APIs.