[PR #4726] [MERGED] Bugfix: Oidc: Properly query the UserInfo Endpoint #6400

New Issue

OVERLORD · 2026-02-05T10:31:17+03:00

OVERLORD commented

2026-02-05 10:31:17 +03:00

📋 Pull Request Information

Original PR: https://github.com/BookStackApp/BookStack/pull/4726
Author: @LukeShu
Created: 12/16/2023
Status: ✅ Merged
Merged: 4/19/2024
Merged by: @ssddanbrown

Base: development ← Head: lukeshu/oidc-development

📝 Commits (1)

c76d12d Oidc: Properly query the UserInfo Endpoint

📊 Changes

5 files changed (+56 additions, -3 deletions)

View changed files

📝 .env.example.complete (+1 -0)
📝 app/Access/Oidc/OidcProviderSettings.php (+6 -1)
📝 app/Access/Oidc/OidcService.php (+12 -0)
📝 app/Config/oidc.php (+1 -0)
📝 tests/Auth/OidcTest.php (+36 -2)

📄 Description

(This is against the development branch; if you think this is worth backporting to release, I have a version of it against the release branch ready-to-go.)

BooksStack's OIDC Client requests the 'profile' and 'email' scope values in order to have access to the 'name', 'email', and other claims. It looks for these claims in the ID Token that is returned along with the Access Token.

However, the OIDC-core specification section 5.4 only requires that the Provider include those claims in the ID Token if an Access Token is not also issued. If an Access Token is issued, the Provider can leave out those claims from the ID Token, and the Client is supposed to obtain them by submitting the Access Token to the UserInfo Endpoint.

So I suppose it's just good luck that the OIDC Providers that BookStack has been tested with just so happen to also stick those claims in the ID Token even though they don't have to. But others (in particular: https://login.infomaniak.com) don't do so, and require fetching the UserInfo Endpoint.)

A workaround is currently possible by having the user write a theme with a ThemeEvents::OIDC_ID_TOKEN_PRE_VALIDATE hook that fetches the UserInfo Endpoint. This workaround isn't great, for a few reasons:

Asking the user to implement core parts of the OIDC protocol is silly.
The user either needs to re-fetch the .well-known/openid-configuration file to discover the endpoint (adding yet another round-trip to each login) or hard-code the endpoint, which is fragile.
The hook doesn't receive the HTTP client configuration.

So, have BookStack's OidcService fetch the UserInfo Endpoint and inject those claims into the ID Token, if a UserInfo Endpoint is defined. Two points about this:

Injecting them into the ID Token's claims is the most obvious approach given the current code structure; though I'm not sure it is the best approach, perhaps it should instead fetch the user info in processAuthorizationResponse() and pass that as an argument to processAccessTokenCallback() which would then need a bit of restructuring. But this made sense because it's also how the ThemeEvents::OIDC_ID_TOKEN_PRE_VALIDATE hook works.
OIDC requires that a UserInfo Endpoint exists, so why bother with that "if a UserInfo Endpoint is defined" bit? Simply out of an abundance of caution that there's an existing BookStack user that is relying on it not fetching the UserInfo Endpoint in order to work with a non-compliant OIDC Provider.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/BookStackApp/BookStack/pull/4726 **Author:** [@LukeShu](https://github.com/LukeShu) **Created:** 12/16/2023 **Status:** ✅ Merged **Merged:** 4/19/2024 **Merged by:** [@ssddanbrown](https://github.com/ssddanbrown) **Base:** `development` ← **Head:** `lukeshu/oidc-development` --- ### 📝 Commits (1) - [`c76d12d`](https://github.com/BookStackApp/BookStack/commit/c76d12d1ded72b5bf74a51fdb1647f87bb935edc) Oidc: Properly query the UserInfo Endpoint ### 📊 Changes **5 files changed** (+56 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `.env.example.complete` (+1 -0) 📝 `app/Access/Oidc/OidcProviderSettings.php` (+6 -1) 📝 `app/Access/Oidc/OidcService.php` (+12 -0) 📝 `app/Config/oidc.php` (+1 -0) 📝 `tests/Auth/OidcTest.php` (+36 -2) </details> ### 📄 Description (This is against the `development` branch; if you think this is worth backporting to `release`, I have a version of it against the `release` branch ready-to-go.) BooksStack's OIDC Client requests the 'profile' and 'email' scope values in order to have access to the 'name', 'email', and other claims. It looks for these claims in the ID Token that is returned along with the Access Token. However, the [OIDC-core specification section 5.4][1] only requires that the Provider include those claims in the ID Token *if* an Access Token is not also issued. If an Access Token is issued, the Provider can leave out those claims from the ID Token, and the Client is supposed to obtain them by submitting the Access Token to the UserInfo Endpoint. So I suppose it's just good luck that the OIDC Providers that BookStack has been tested with just so happen to also stick those claims in the ID Token even though they don't have to. But others (in particular: https://login.infomaniak.com) don't do so, and require fetching the UserInfo Endpoint.) A workaround is currently possible by having the user write a theme with a ThemeEvents::OIDC_ID_TOKEN_PRE_VALIDATE hook that fetches the UserInfo Endpoint. This workaround isn't great, for a few reasons: 1. Asking the user to implement core parts of the OIDC protocol is silly. 2. The user either needs to re-fetch the .well-known/openid-configuration file to discover the endpoint (adding yet another round-trip to each login) or hard-code the endpoint, which is fragile. 3. The hook doesn't receive the HTTP client configuration. So, have BookStack's OidcService fetch the UserInfo Endpoint and inject those claims into the ID Token, if a UserInfo Endpoint is defined. Two points about this: - Injecting them into the ID Token's claims is the most obvious approach given the current code structure; though I'm not sure it is the best approach, perhaps it should instead fetch the user info in processAuthorizationResponse() and pass that as an argument to processAccessTokenCallback() which would then need a bit of restructuring. But this made sense because it's also how the ThemeEvents::OIDC_ID_TOKEN_PRE_VALIDATE hook works. - OIDC *requires* that a UserInfo Endpoint exists, so why bother with that "if a UserInfo Endpoint is defined" bit? Simply out of an abundance of caution that there's an existing BookStack user that is relying on it not fetching the UserInfo Endpoint in order to work with a non-compliant OIDC Provider. [1]: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-05 10:31:17 +03:00

OVERLORD closed this issue

2026-02-05 10:31:18 +03:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#6400