[Koha-bugs] [Bug 34755] Error authenticating to external OpenID Connect (OIDC) identity provider : wrong_csrf_token

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34755

Olivier Hubert <olivier.hubert at inlibro.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---
                 CC|                            |olivier.hubert at inlibro.com

--- Comment #2 from Olivier Hubert <olivier.hubert at inlibro.com> ---
I am reopening this bug as we noticed this exact problem happening with our
only instance using SSO (and because Jonathan mentioned I should reopen the bug
instead of creating a new one). I have reproduced the bug using Koha Testing
Docker.

Steps to reproduce, assuming you're using Koha Testing Docker, properly
configured with Keycloak, although this might work using other configurations
as well:

1. Open the OPAC
2. Log in with a regular Koha user, not using SSO.
3. In a private browser window, open the OPAC
4. log in using SSO with a different user account.
5. Notice that you get the error message "There was an error authenticating to
external identity provider

wrong_csrf_token"
6. Click on the "Log in with [...]" button, to log in again using SSO.
7. Notice that the user is immediately logged in.

I have figured out part of the problem. It seems that when first loading the
OPAC, the userenv variable is loaded with the latest session data instead of no
data at all (e.g. anonymous). By adding a warning on line 224 of Koha/Token.pm,
I can get the id on the first OPAC visit, as well as the id when returning from
the SSO authentication. If I first login with a user named "koha", at step 2 of
my steps to reproduce, I get something like this in plack-api-error.log:

[2024/01/12 19:49:08] [WARN] The id for generating the CSRF token is:
koha_16b598a250e8b2a9de9b3d94ec89d2c9 at /kohadevbox/koha/Koha/Token.pm line
224.
[2024/01/12 19:49:13] [WARN] The id for generating the CSRF token is:
anonymous_16b598a250e8b2a9de9b3d94ec89d2c9 at /kohadevbox/koha/Koha/Token.pm
line 224.

As you can see, the session id is the same, so the session is successfully
saved and reused. But it seems the anonymisation happens after the userenv
variable is used, and therefore the last used session username is used for
generating the CSRF token instead of "anonymous".

Note that getting "anonymous" on returning from authentication (step 5) is not
guaranteed. On a very busy instance, I was able to get the last used session
username instead.

Also note that you can prevent the issue by reloading the OPAC page between
step 3 and 4. If no one else has a more recent session, then the SSO login will
work on the first try.

-- 
You are receiving this mail because:
You are watching all bug changes.