andrew-chen-wang / django-social-provider-and-consumer-tutorial Goto Github PK

Turns out, when I used PKCE_REQUIRED=True, nothing happened because I didn't add that to the OAUTH2_PROVIDER dictionary which is where django oauth toolkit gets their settings from. I just assumed allauth took care of it (even though I was pretty skeptical). Anyways, finally it showed its true colors so I'll be implementing that now.

This is the code that requires PKCE: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py#L19

This is an article that can help: https://www.liip.ch/en/blog/authorization-code-with-pkce-on-django-using-django-oauth-toolkit

edit (took 5 minutes to figure out how this actually works... well hopefully) here is what I think needs to happen: https://github.com/Andrew-Chen-Wang/react-native-oauth-login/issues/1#issuecomment-860150418

User is saved without password. EmailAddress is created in db as well and FK is linked properly. But I keep seeing the provider's web page saying "Authorize" even though the user obviously already authorized... hmm

Upon further inspection, it seems like what should instead happen is not have redirect uri for any social consumer on native apps. Instead, if you need to add a "Login with Velnota" button, it should first go to your website which performs the redirect where the user logs in. Then the callback is given to the consumer which then performs the redirect uri on the app...

Turns out, the redirect scheme for the mobile app can be https and is recommended in rfc8252: https://datatracker.ietf.org/doc/html/rfc8252#section-7.1

Basically, that custom scheme is only useful for private redirect Uris. It's not particularly helpful if you create an OAuth provider that allows for anyone to register an application because in that case you'll have to keep updating the redirect uri scheme with every new application (or override the django oauth toolkit Application to allow all redirect Uris which in this case isn't necessary).

When you take a look at section 7.2, it explicitly says:

App-claimed "https" scheme redirect URIs have some advantages
compared to other native app redirect options in that the identity of
the destination app is guaranteed to the authorization server by the
operating system. For this reason, native apps SHOULD use them over
the other options where possible.

And in section 8.4:

For private-use URI scheme-based redirects, authorization servers
SHOULD enforce the requirement in Section 7.1 that clients use
schemes that are reverse domain name based. At a minimum, any
private-use URI scheme that doesn't contain a period character (".")
SHOULD be rejected.

In addition to the collision-resistant properties, requiring a URI
scheme based on a domain name that is under the control of the app
can help to prove ownership in the event of a dispute where two apps
claim the same private-use URI scheme (where one app is acting
maliciously). For example, if two apps claimed "com.example.app",
the owner of "example.com" could petition the app store operator to
remove the counterfeit app. Such a petition is harder to prove if a
generic URI scheme was used.