OpenID Connect (OIDC) with Google (Sessions issue?) #4297

New Issue

OVERLORD · 2026-02-05T08:27:50+03:00

OVERLORD commented

2026-02-05 08:27:50 +03:00

Originally created by @jorismak on GitHub (Nov 3, 2023).

Attempted Debugging

I have read the debugging page

Searched GitHub Issues

I have searched GitHub for the issue.

Describe the Scenario

Using the solidnerd/bookstack docker image
I can't seem to get a storage/logs/laravel.log file. All the folders are 'chmod 777' and I've created the file with the www-data user. Userid matches my host www-data and the docker www-data, so really no issue there. I can run a shell in the running docker image (as the www-data user) and create a file in storage/logs no problem. Also appending (with 'echo') to to existing zero-byte laravel.log file works. So it really doesn't seem to be a permission issue.
The 'logs' that I see as the docker container are the logs of the apache webserver.
I first setup a working OAuth 'social' login with Google in our workspace. That worked. So I have a working 'Login with Google' button, and users are auto-registered with it and logging in works fine.
But, we want to use it as the only option. So instead of AUTH_METHOD=standard with a google social login, I configure OpenID connect. I use the same oauth client_id / client_secret, add the redirect url in Google, configure OIDC_ISSUERas 'https://accounts.google.com'.

    -e AUTH_METHOD=oidc \
    -e AUTH_AUTO_INITIATE=false \
    -e OIDC_NAME="OV Google" \
    -e OIDC_DISPLAY_NAME_CLAIMS=name \
    -e OIDC_CLIENT_ID=redacted.apps.googleusercontent.com \
    -e OIDC_CLIENT_SECRET=redacted \
    -e OIDC_ISSUER=https://accounts.google.com \
    -e OIDC_ISSUER_DISCOVER=true \

Now here comes the tricky part. Logging in from Chrome based browsers (Chrome mac / Chrome windows, Edge windows, Brave mobile, Chrome mobile) it appears to work. But after Google redirects us back to BookStack, we get an error in the corner:

Looking through the code it seems to be that the OAuth State doesn't match what is in the session.
I notice that every time I refresh a page (even the 404 page) I get another value in the session cookie. Even Javascripts and such set a different session cookie value (so if you watch in the Chrome devtools in the 'Application' tab, you'll see the session cookie changes very rapidly on page-reload). But this might be by design?

The thing is, it works fine on Firefox it seems ?!?!. I tried in Incognito windows, disabling all extensions, disabling tracking-prevention, ...

Since I can't seem to get any error logs it's kind hard to get a feeling where to look next. In the 'network' tab I do see that Google gives back a state (of course), but I'm suspicious of the 'bookstack_session' cookie changing value on each request(cookie-parameters seem fine otherwise).

Also as a reminder, changing the AUTH_METHOD to 'standard' and logging in seems to work fine (as did the Google 'social' login). So sessions do seem to work fine.

All my env vars:

    -e APP_KEY="redacted" \
    -e APP_URL=https://redacted \
    -e APP_DEBUG=true \            # tried with false or without it being set first
    -e DB_DATABASE=bookstack \
    -e DB_HOST=host.docker.internal:3306 \
    -e DB_USERNAME=bookstack \
    -e DB_PASSWORD=redacted \
    -e MAIL_DRIVER=smtp \
    -e MAIL_HOST=host.docker.internal \
    -e MAIL_PORT=25 \
    -e MAIL_EMCRYPTION=null \
    -e MAIL_VERIFY_SSL=false \
    -e MAIL_FROM=redacted \
    -e MAIL_FROM_NAME="redacted" \
    -e APP_TIMEZONE=Europe/Amsterdam \
    -e APP_PROXIES=127.0.0.1,172.17.0.1 \
    -e AUTH_METHOD=oidc \
    -e AUTH_AUTO_INITIATE=false \
    -e OIDC_NAME="OV Google" \
    -e OIDC_DISPLAY_NAME_CLAIMS=name \
    -e OIDC_CLIENT_ID=redacted \
    -e OIDC_CLIENT_SECRET=redacted \
    -e OIDC_ISSUER=https://accounts.google.com \
    -e OIDC_ISSUER_DISCOVER=true \
    -e LOG_CHANNEL=single \ # Attempt to get something in the laravel.log file
    -e SESSION_LIFETIME=1440 \  # Attempt to make sure sessions live long enough to not have timezone issues or something
    -e SESSION_DRIVER=database \  # Attempt to see if the file-based storage in the docker-container was an issue

Exact BookStack Version

23.10.0

Log Content

No response

Hosting Environment

Docker image running PHP 8.2, Linux Ubuntu 22.04 docker host, https://github.com/solidnerd/docker-bookstack docker image.

The host is running nginx and using that as a reverse proxy to the docker exposed port

    location / {
        proxy_pass          http://bookstack;
        proxy_redirect      off;
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto https;
        proxy_set_header    X-Forwarded-Port 443;
        proxy_buffer_size   128k;
        proxy_buffers       4 256k;
        proxy_busy_buffers_size 256k;
        proxy_read_timeout  600;
    }

Originally created by @jorismak on GitHub (Nov 3, 2023). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario 1) Using the solidnerd/bookstack docker image 2) I can't seem to get a storage/logs/laravel.log file. All the folders are 'chmod 777' and I've created the file with the www-data user. Userid matches my host www-data and the docker www-data, so really no issue there. I can run a shell in the running docker image (as the www-data user) and create a file in storage/logs no problem. Also appending (with 'echo') to to existing zero-byte laravel.log file works. So it really doesn't seem to be a permission issue. 3) The 'logs' that I see as the docker container are the logs of the apache webserver. 4) I first setup a working OAuth 'social' login with Google in our workspace. That worked. So I have a working 'Login with Google' button, and users are auto-registered with it and logging in works fine. 5) But, we want to use it as the only option. So instead of AUTH_METHOD=standard with a google social login, I configure OpenID connect. I use the same oauth client_id / client_secret, add the redirect url in Google, configure OIDC_ISSUERas 'https://accounts.google.com'. ``` -e AUTH_METHOD=oidc \ -e AUTH_AUTO_INITIATE=false \ -e OIDC_NAME="OV Google" \ -e OIDC_DISPLAY_NAME_CLAIMS=name \ -e OIDC_CLIENT_ID=redacted.apps.googleusercontent.com \ -e OIDC_CLIENT_SECRET=redacted \ -e OIDC_ISSUER=https://accounts.google.com \ -e OIDC_ISSUER_DISCOVER=true \ ``` 6) Now here comes the tricky part. Logging in from Chrome based browsers (Chrome mac / Chrome windows, Edge windows, Brave mobile, Chrome mobile) it appears to work. But after Google redirects us back to BookStack, we get an error in the corner: ![image](https://github.com/BookStackApp/BookStack/assets/47725838/69bfc449-412e-4062-8b77-f5fa92ed5d70) Looking through the code it seems to be that the OAuth State doesn't match what is in the session. I notice that every time I refresh a page (even the 404 page) I get another value in the session cookie. Even Javascripts and such set a different session cookie value (so if you watch in the Chrome devtools in the 'Application' tab, you'll see the session cookie changes very rapidly on page-reload). But this might be by design? The thing is, it works fine on Firefox it seems ?!?!. I tried in Incognito windows, disabling all extensions, disabling tracking-prevention, ... Since I can't seem to get any error logs it's kind hard to get a feeling where to look next. In the 'network' tab I do see that Google gives back a state (of course), but I'm suspicious of the 'bookstack_session' cookie changing value on each request(cookie-parameters seem fine otherwise). Also as a reminder, changing the AUTH_METHOD to 'standard' and logging in seems to work fine (as did the Google 'social' login). So sessions do seem to work fine. All my env vars: ``` -e APP_KEY="redacted" \ -e APP_URL=https://redacted \ -e APP_DEBUG=true \ # tried with false or without it being set first -e DB_DATABASE=bookstack \ -e DB_HOST=host.docker.internal:3306 \ -e DB_USERNAME=bookstack \ -e DB_PASSWORD=redacted \ -e MAIL_DRIVER=smtp \ -e MAIL_HOST=host.docker.internal \ -e MAIL_PORT=25 \ -e MAIL_EMCRYPTION=null \ -e MAIL_VERIFY_SSL=false \ -e MAIL_FROM=redacted \ -e MAIL_FROM_NAME="redacted" \ -e APP_TIMEZONE=Europe/Amsterdam \ -e APP_PROXIES=127.0.0.1,172.17.0.1 \ -e AUTH_METHOD=oidc \ -e AUTH_AUTO_INITIATE=false \ -e OIDC_NAME="OV Google" \ -e OIDC_DISPLAY_NAME_CLAIMS=name \ -e OIDC_CLIENT_ID=redacted \ -e OIDC_CLIENT_SECRET=redacted \ -e OIDC_ISSUER=https://accounts.google.com \ -e OIDC_ISSUER_DISCOVER=true \ -e LOG_CHANNEL=single \ # Attempt to get something in the laravel.log file -e SESSION_LIFETIME=1440 \ # Attempt to make sure sessions live long enough to not have timezone issues or something -e SESSION_DRIVER=database \ # Attempt to see if the file-based storage in the docker-container was an issue ``` ### Exact BookStack Version 23.10.0 ### Log Content _No response_ ### Hosting Environment Docker image running PHP 8.2, Linux Ubuntu 22.04 docker host, https://github.com/solidnerd/docker-bookstack docker image. The host is running nginx and using that as a reverse proxy to the docker exposed port ``` location / { proxy_pass http://bookstack; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-Port 443; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; proxy_read_timeout 600; } ```

OVERLORD added the 🐕 Support label 2026-02-05 08:27:50 +03:00

OVERLORD closed this issue

2026-02-05 08:27:52 +03:00

OVERLORD commented

2026-02-05 08:28:03 +03:00

@ssddanbrown commented on GitHub (Nov 3, 2023):

Hi @jorismak,

I can't seem to get a storage/logs/laravel.log

For this scenario, I wouldn't expect anything to be logged to the log file, so possibly just nothing being logged here.

I notice that every time I refresh a page (even the 404 page) I get another value in the session cookie.

Yeah, that's intentional in correct working usage.

Looking through the code it seems to be that the OAuth State doesn't match what is in the session.

Yeah, that's correct.
So I'd expect that something is affecting cookie/session state.
Since it sounds like it's specifically affecting this flow (since other BookStack use sounds unaffected) that makes me thing that something like Strict same site cookies are in use. Do you have any configuration, on your nginx proxy or at any other HTTP layer (other proxies or things like Cloudflare) in play, that is setting additional HTTP headers/options for security?

Additionally, are you able to view the details of the session cookie in the browser and confirm the SameSite property at all?

@ssddanbrown commented on GitHub (Nov 3, 2023): Hi @jorismak, > I can't seem to get a storage/logs/laravel.log For this scenario, I wouldn't expect anything to be logged to the log file, so possibly just nothing being logged here. > I notice that every time I refresh a page (even the 404 page) I get another value in the session cookie. Yeah, that's intentional in correct working usage. > Looking through the code it seems to be that the OAuth State doesn't match what is in the session. Yeah, that's correct. So I'd expect that something is affecting cookie/session state. Since it sounds like it's specifically affecting this flow (since other BookStack use sounds unaffected) that makes me thing that something like [Strict same site cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#strict) are in use. Do you have any configuration, on your nginx proxy or at any other HTTP layer (other proxies or things like Cloudflare) in play, that is setting additional HTTP headers/options for security? Additionally, are you able to view the details of the session cookie in the browser and confirm the `SameSite` property at all?

OVERLORD commented

2026-02-05 08:28:06 +03:00

@jorismak commented on GitHub (Nov 3, 2023):

Thanks for thinking along!

It seems it's Lax (didn't change it anywhere).

I think I set cookie secure to 'true' at the beginning, later removed it, but it seems it set at 'secure' anyway (which seems correct to me).

No cloudflare or anything. From the browser directly to our VPS server where nginx takes the request, which reverse-proxies to the docker container (which is running Apache with the php module if I see it right).

@jorismak commented on GitHub (Nov 3, 2023): Thanks for thinking along! It seems it's Lax (didn't change it anywhere). I think I set cookie secure to 'true' at the beginning, later removed it, but it seems it set at 'secure' anyway (which seems correct to me). No cloudflare or anything. From the browser directly to our VPS server where nginx takes the request, which reverse-proxies to the docker container (which is running Apache with the php module if I see it right). ![image](https://github.com/BookStackApp/BookStack/assets/47725838/52f8e019-f9b8-4e81-bdf1-2dd2390525a5)

OVERLORD commented

2026-02-05 08:28:14 +03:00

@ssddanbrown commented on GitHub (Nov 3, 2023):

Okay, those BookStack Cookies look fine, although that extra shortscc cookie piques my interest.
Looks potentially related to some kind of cookie control system?
Depending on where that exists, could maybe be affecting things.

Otherwise, it's worth checking the flow back ground Google during the OIDC login, to ensure there are no additional redirects within the journey that are throwing things off.
For this, I'd watch the Network tab of the devtools, with "Persist Logs" (or similar) enabled, then go through the auth flow.
After going through google you should be redirected once back to <bookstack_url>/oidc/callback. If this has any double slashes, or if there is an extra redirect to a similar URL, or if the one redirect back does not exactly match the instance URL (including https/http starting protol), then that'd be worth looking into further.

@ssddanbrown commented on GitHub (Nov 3, 2023): Okay, those BookStack Cookies look fine, although that extra `shortscc` cookie piques my interest. Looks potentially related to some kind of cookie control system? Depending on where that exists, could maybe be affecting things. Otherwise, it's worth checking the flow back ground Google during the OIDC login, to ensure there are no additional redirects within the journey that are throwing things off. For this, I'd watch the Network tab of the devtools, with "Persist Logs" (or similar) enabled, then go through the auth flow. After going through google you should be redirected once back to `<bookstack_url>/oidc/callback`. If this has any double slashes, or if there is an extra redirect to a similar URL, or if the one redirect back does not exactly match the instance URL (including https/http starting protol), then that'd be worth looking into further.

OVERLORD commented

2026-02-05 08:28:17 +03:00

@jorismak commented on GitHub (Nov 3, 2023):

Thanks, has to be next week again but I'll look at it.
I had the network tab open to see things before, and there are some 'pings'
to play.google.com, I guess for logging / analytics for the OAuth setup or
something.

'shortscc' might be an browser extension to hide Youtube Shorts.
Interesting that it injects itself in all domains.....

On Fri, 3 Nov 2023 at 12:43, Dan Brown @.***> wrote:

Okay, those BookStack Cookies look fine, although that extra shortscc
cookie piques my interest.
Looks potentially related to some kind of cookie control system?
Depending on where that exists, could maybe be affecting things.

Otherwise, it's worth checking the flow back ground Google during the OIDC
login, to ensure there are no additional redirects within the journey that
are throwing things off.
For this, I'd watch the Network tab of the devtools, with "Persist Logs"
(or similar) enabled, then go through the auth flow.
After going through google you should be redirected once back to
<bookstack_url>/oidc/callback. If this has any double slashes, or if
there is an extra redirect to a similar URL, or if the one redirect back
does not exactly match the instance URL (including https/http starting
protol), then that'd be worth looking into further.

—
Reply to this email directly, view it on GitHub
https://github.com/BookStackApp/BookStack/issues/4647#issuecomment-1792293781,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALMD2DXQTMYZLDMMIQKHGBDYCTKGNAVCNFSM6AAAAAA64EM7DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGI4TGNZYGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@jorismak commented on GitHub (Nov 3, 2023): Thanks, has to be next week again but I'll look at it. I had the network tab open to see things before, and there are some 'pings' to play.google.com, I guess for logging / analytics for the OAuth setup or something. 'shortscc' might be an browser extension to hide Youtube Shorts. Interesting that it injects itself in all domains..... On Fri, 3 Nov 2023 at 12:43, Dan Brown ***@***.***> wrote: > Okay, those BookStack Cookies look fine, although that extra shortscc > cookie piques my interest. > Looks potentially related to some kind of cookie control system? > Depending on where that exists, could maybe be affecting things. > > Otherwise, it's worth checking the flow back ground Google during the OIDC > login, to ensure there are no additional redirects within the journey that > are throwing things off. > For this, I'd watch the Network tab of the devtools, with "Persist Logs" > (or similar) enabled, then go through the auth flow. > After going through google you should be redirected once back to > <bookstack_url>/oidc/callback. If this has any double slashes, or if > there is an extra redirect to a similar URL, or if the one redirect back > does not exactly match the instance URL (including https/http starting > protol), then that'd be worth looking into further. > > — > Reply to this email directly, view it on GitHub > <https://github.com/BookStackApp/BookStack/issues/4647#issuecomment-1792293781>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ALMD2DXQTMYZLDMMIQKHGBDYCTKGNAVCNFSM6AAAAAA64EM7DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJSGI4TGNZYGE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

OVERLORD commented

2026-02-05 08:28:24 +03:00

@ssddanbrown commented on GitHub (Dec 3, 2023):

Since there's been no further follow-up over the last month I'll close this off but feel free to comment, and this can be re-opened if required.

@ssddanbrown commented on GitHub (Dec 3, 2023): Since there's been no further follow-up over the last month I'll close this off but feel free to comment, and this can be re-opened if required.

OVERLORD commented

2026-02-05 08:28:26 +03:00

@jorismak commented on GitHub (Dec 3, 2023):

Oh.. excuses for not following up. Election season here exploded and my attention was elsewhere .

About this issue , it started 'magically' working. Which I hate cause I don't like not having a clear cause.t deployment was in git through Ansible . Looking back I see no clear changes in config that could've caused it to work (slashes, redirect url, etc...). Maybe the config over at Google needed time to accept to a change or something ?

Rightfully closed right now, I'll open another issue if it's ever bothering me again . Thanks for helping !

@jorismak commented on GitHub (Dec 3, 2023): Oh.. excuses for not following up. Election season here exploded and my attention was elsewhere . About this issue , it started 'magically' working. Which I hate cause I don't like not having a clear cause.t deployment was in git through Ansible . Looking back I see no clear changes in config that could've caused it to work (slashes, redirect url, etc...). Maybe the config over at Google needed time to accept to a change or something ? Rightfully closed right now, I'll open another issue if it's ever bothering me again . Thanks for helping !

OVERLORD commented

2026-02-05 08:28:28 +03:00

@ssddanbrown commented on GitHub (Dec 3, 2023):

Good to hear it did eventually start working.

Maybe the config over at Google needed time to accept to a change or something ?

That could totally be it! Don't think it's the first time I've had someone report strange behaviour with Google Auth which was fixed by waiting a day.

@ssddanbrown commented on GitHub (Dec 3, 2023): Good to hear it did eventually start working. > Maybe the config over at Google needed time to accept to a change or something ? That could totally be it! Don't think it's the first time I've had someone report strange behaviour with Google Auth which was fixed by waiting a day.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#4297