Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

session cookie not sent #497

Open
l1ll1 opened this issue Jun 29, 2023 · 2 comments
Open

session cookie not sent #497

l1ll1 opened this issue Jun 29, 2023 · 2 comments

Comments

@l1ll1
Copy link

l1ll1 commented Jun 29, 2023

Hi,
I don't know if this is really a mozzila-djano-oidc issue, or an django issue, but I've just been configuring an RP for google OIDC. I found that my client (chromium and firefox) were not transmitting the django sessionid cookie to the callback url because it has SameSite=Strict (and the calling url was google.com). The result was the mozilla-django-oidc couldn't get the oidc_claims from the session.

I "fixed" the problem by setting SESSION_COOKIE_SAMESITE='Lax' in config/auth.py so that the sessionid was transmitted.

I wonder whether
a) anyone else has experienced this
b) I'm doing something hideously wrong and that's why no one else seems to have hit this problem

For context I'm actually using an application called coldfront which is subclassing OIDCAuthenticationBackend,
I'm on django 3.2.17 and mozilla-django-oidc 3.0.0 and chromium 114.0.5735.106 with a google OIDC provider. I suspect this will affect anyone using mozilla-django-oidc where the OIDC Provider and RP are not on the same domain (eg using google for the provider for an RP on your own domain)

Thanks for you time ;-)

@kyre6371
Copy link

kyre6371 commented Apr 11, 2024

I had this same issue with coldfront! When diagnosing the problem, I was catching http requests. It gets the code and state that is used to get the access token. so if you get the code and state, you can paste it into the url like: https://my-url/oidc/callback/?code=<code>&state=<state> and it would log in every time. Not very practical.

I've messaged the coldfront team on slack about this as well. I thought it was an ssl issue for a while. Thanks for posting this.

@Timost
Copy link

Timost commented Jun 11, 2024

Got the same issue, found this issue on another project. pennersr/django-allauth#3232

That leads to this https://stackoverflow.com/questions/42216700/how-can-i-redirect-after-oauth2-with-samesite-strict-and-still-get-my-cookies and a proposed solution:

One more possible solution: Set the session token to SameSite: Lax during the beginning of the OAuth flow, then upgrade it to SameSite: Strict in the OAuth callback. The damage a cross-origin request can do is limited if they don't yet have a session.

sergei-maertens added a commit to GPP-Woo/GPP-publicatiebank that referenced this issue Sep 17, 2024
Ideally we set this to Strict, but the session cookie is now not sent
during redirects from OIDC providers (like Google, Azure, Keycloak)
after succesful authentication, causing crashes on our end because
we don't have access to the OIDC state and therefore we have a broken
reference to the OIDC config model being used.

See mozilla/mozilla-django-oidc#497 for more
information - in summary the best solution would be to set it to Strict,
but temporarily reduce this to Lax during the OIDC flow (possibly via
middleware), which will require overriding some django.contrib.sessions
middleware.
bart-maykin pushed a commit to GPP-Woo/GPP-publicatiebank that referenced this issue Sep 20, 2024
Ideally we set this to Strict, but the session cookie is now not sent
during redirects from OIDC providers (like Google, Azure, Keycloak)
after succesful authentication, causing crashes on our end because
we don't have access to the OIDC state and therefore we have a broken
reference to the OIDC config model being used.

See mozilla/mozilla-django-oidc#497 for more
information - in summary the best solution would be to set it to Strict,
but temporarily reduce this to Lax during the OIDC flow (possibly via
middleware), which will require overriding some django.contrib.sessions
middleware.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants