External-Mirrors/keycloak
2
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-10 15:32:05 -03:30
Code Issues Packages Projects Releases Wiki Activity

Update upgrading notes with the changes related to core clients (#35860)

Browse Source 
closes #35859

Signed-off-by: mposolda <mposolda@gmail.com>


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>
Signed-off-by: Marek Posolda <mposolda@gmail.com>
This commit is contained in:
Marek Posolda 2024-12-13 10:12:37 +01:00 committed by GitHub
parent 47753b9624
commit 0265cb6254
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/documentation/upgrading/topics/changes/changes-26_1_0.adoc
View File

@ -10,9 +10,12 @@ Notable changes where an internal behavior changed to prevent common misconfigur
=== Offline access removes the associated online session if the `offline_scope` is requested in the initial exchange
Any offline session in {project_name} is created from another online session. When the `offline_access` scope is requested, the current online session is used to create the associated offline session for the client. Therefore any `offline_access` request finished, until now, with two sessions, one online and one offline.
Any offline session in {project_name} is created from an online session. When the `offline_access` scope is requested, the current online session is used to create the associated offline session for the client. Therefore, any `offline_access` request finished, until now, created two sessions: one online and one offline.
This situation lead to unreliable behavior. For example, when just the login with `scope=offline_access` was requested, there could be an unused online session created, which is then useless in most cases.
This situation caused the unnecessary consumption of server resources.
Starting with this version, {project_name} removes the initial online session if the `offline_scope` is directly requested as the first interaction for the session. The client retrieves the offline token after the code to token exchange that is associated to the offline session, but the previous online session is removed. If the online session has been used before the `offline_scope` request, by the same or another client, the online session remains active as today. Although the new behavior makes sense because the client application is just asking for an offline token, it can affect some scenarios that rely on having the online session still active after the initial `offline_scope` token request.
Starting with this version, {project_name} removes the initial online session if the `offline_scope` is directly requested as the first interaction for the session. The client retrieves the offline token after the code to token exchange that is associated to the offline session, but the previous online session is removed. If the online session has been used before the `offline_scope` request, by the same or another client, the online session remains active as today.
This situation also means that the SSO session is not created in the browser if the login request with `scope=offline_access` is used and the user was not already authenticated in the SSO beforehand. Although the new behavior makes sense because the client application is just asking for an offline token, it can affect some scenarios that rely on having the online session still active after the initial `offline_scope` token request.
=== New client scope `service_account` for `client_credentials` grant mappers
@ -20,6 +23,10 @@ Starting with this version, {project_name} removes the initial online session if
Previously, the three mappers (`Client Id`, `Client Host` and `Client IP Address`) where added directly to the dedicated scope when the client was configured to enable service accounts, and they were never removed.
The behavior should be effectively the same for most {project_name} deployments because claims in the token are effectively same as before. You might be affected in cases when you are using a client credentials grant
and you are preparing the {project_name} environment by some tooling that is manually removing or updating the three protocol mappers mentioned above. For instance, if you use an admin CLI script to enable a service-account for a client and then remove the built-in service-account protocol mappers, you may adjust your CLI to instead remove the assignment of the `service_account` client scope
from the client instead of removing protocol mappers.
== Deprecation notices
This lists functionality that continues to work as before in this release, but will be removed in a future major release.