Supporting Facebook "Limited Login"

[Rjevski]

I would like to get opinions on what's the best way to implement Facebook's Limited Login.

It's a JWT-based scheme with the JWT obtained out-of-band and we should merely validate it and extract user metadata from it. This JWT does not allow access to any Facebook APIs - it's purely there as an assertion to say "I am Facebook and am vouching for this user with this ID and this metadata".

Now for the fun bit - the UIDs are shared between this and the main Facebook provider, and we must thus support both flows within the same provider (a user will use Limited Login on iOS, but normal oAuth2-based login on web for example - Limited Login doesn't seem to exist on the web). We can't use separate providers because otherwise a user would end up with 2 social logins against their account - one from the limited login provider and one from the normal provider.

The problem I see is that the existing Facebook provider is heavily biased towards oAuth2 and in fact relies on access to the Graph API. I am thinking, as a hack/proof of concept:

• subclass the Facebook provider
• override the verify_token function to check if there is an id_token in the token kwarg
• if there is, pass it to a new function like flows.verify_limited_login_token (copied from flows.verify_token)
• that function will create a SocialToken with the JWT in the token kwarg - edit: I don't think SocialToken is mandatory, so in this case we skip it as we don't actually have a real token that allows Graph API access
• then, to create the actual "login", it will call provider.sociallogin_from_response(request, extra_data) with the extra_data being the JWT metadata such as email, name, etc - mimicking what would normally be a Graph API response
• at this point I think this will be enough to identify and login a user, but it will break many assumptions elsewhere that the SocialToken.token is a valid bearer token for the Graph API

Other thoughts to consider:

• replay attack prevention - once a JWT is "consumed", it should be locally recorded as used (up until its own expiry - at which point it becomes invalid regardless) so that if the user subsequently disconnects said FB account, they (or rather an attacker somehow getting ahold of this JWT) can't reconnect it behind the scenes - instead they'd need to get a new JWT

Any thoughts/suggestions on this? I will be happy to submit PRs.

[pennersr]

Must admit, I haven't taken the time to study any of this, but it does sound very familiar to the Google provider. For example, Google One Tap Sign-In allows for signing in via an ID token. You can check that for reference.

[Rjevski]

Got a solution that works reliably, PR submitted on Codeberg: https://codeberg.org/allauth/django-allauth/pulls/4151