search

supabase-community / auth-py

Python client implementation for Supabase Auth
MIT License
60 stars 33 forks source link

bug for server side to generate verifier and challenge pairs #505

Open nullne opened 1 month ago

nullne commented 1 month ago

https://github.com/supabase-community/auth-py/blob/16e571fc19168314d82074523de6f246bdd74960/supabase_auth/_sync/gotrue_client.py#L943C9-L952C1

for example: user A generates a url, with verifier A, user A doesn't verify immediately then, user A generate another url, for now, previous url won't be verified by the new code_verifier

silentworks commented 1 month ago

I'm not understanding your explanation above. Can you use example along with step by step instructions of the issue please?

nullne commented 1 month ago

let me try to explain again before deploying a demo :)

in "pkce" mode, step1, a google login link is generated and not clicked. if you dive deep into the related code, a code_verifier is generated and saved to memory by default which is used to validate the code_challenge later . step2, generate the google login link again, this time, a new code_verifier generated and cannot match the previous code_challenge, this is the problem

silentworks commented 1 month ago

You've just described how PKCE works. This is not a bug, it's just how the feature works.

nullne commented 1 month ago

it's ok for frontend lib, because browser remembers which verifier key is used, but for backend, it generate verifier key in one request, and verify it in another, in which scene backend can't remember which verifier key for which challenge.

silentworks commented 1 month ago

I'm looking into this to see what's the best way to handle it with current setup. Ideally we need to get the authorization code flow from Supabase, but this hasn't been implemented as yet into Supabase's auth setup.

silentworks commented 2 weeks ago

So I have a solution for this which would mean saving the sessions as cookies and then retrieving them on a per request basis. In my current setup I'm using cookies and redis, the cookie stores the session_id and redis stores the actual JWT with the session_id for the lookup. I'm going to try and create a repo with this for others to see how its implemented, I'm also almost certain it can be done with cookies only without redis, however the benefit of redis is that its a quick in memory storage and you can store larger bytes in it than a cookie.

nullne commented 2 weeks ago

So I have a solution for this which would mean saving the sessions as cookies and then retrieving them on a per request basis. In my current setup I'm using cookies and redis, the cookie stores the session_id and redis stores the actual JWT with the session_id for the lookup. I'm going to try and create a repo with this for others to see how its implemented, I'm also almost certain it can be done with cookies only without redis, however the benefit of redis is that its a quick in memory storage and you can store larger bytes in it than a cookie.

it should work. for now is there any method to pass cookies to verify code_challenge?