Documentation for latest logout changes (#1624)

* Documentation for latest logout changes
Closes #1545


Co-authored-by: andymunro <48995441+andymunro@users.noreply.github.com>

release_notes/topics/19_0_0.adoc

@@ -45,6 +45,18 @@ Hence, custom extensions that access objects in local storage or cache through `
 methods must be reviewed.
 See link:{upgradingguide_link}[{upgradingguide_name}] for details.
 
+= OIDC Logout changes
+
+In the previous release, we added support for OIDC logout. This release contains a few other fixes and polishing. The  highlights include:
+
+- Support for the `client_id` parameter, which was added in recent draft of the OIDC RP-Initiated Logout specification. As a result, no need exists to use the `Consent Required` flag of the
+client to show the logout confirmation screen.
+- Configuration option `Valid Post Logout Redirect URIs` added to the OIDC client. This change is aligned with the OIDC specification, which allows you to use a different set of redirect URIs for redirect after login and logout.
+Value `+` used for `Valid Post Logout Redirect URIs` means that the logout will use the same set of redirect URIs as specified by the option of `Valid Redirect URIs`. This change also matches the default behavior when migrating
+from a previous version due to backwards compatibility.
+
+For more details, see the link:{adminguide_link}#_oidc-logout[{adminguide_name}].
+
 = Deprecated `podDisruptionBudget` in the legacy {project_operator}
 
 With this release, we have deprecated `podDisruptionBudget` field in the Keycloak CR of the https://github.com/keycloak/keycloak-operator[legacy {project_operator}].

securing_apps/topics/oidc/java/logout.adoc

@@ -4,9 +4,10 @@
 You can log out of a web application in multiple ways.
 For Jakarta EE servlet containers, you can call `HttpServletRequest.logout()`. For other browser applications, you can redirect the browser to
 `\http://auth-server{kc_realms_path}/{realm-name}/protocol/openid-connect/logout`, which logs the user out if that user has an SSO session with his browser. The actual logout is done once
-the user confirms the logout. You can optionally include parameters such as `id_token_hint`, `post_logout_redirect_uri` and others as described in the
+the user confirms the logout. You can optionally include parameters such as `id_token_hint`, `post_logout_redirect_uri`, `client_id` and others as described in the
 https://openid.net/specs/openid-connect-rpinitiated-1_0.html[OpenID Connect RP-Initiated Logout]. As a result, that logout does not need to be explicitly confirmed
-by the user.
+by the user if you include the `id_token_hint` parameter. After logout, the user will be automatically redirected to the specified `post_logout_redirect_uri` as long as it is provided.
+Note that you need to include either the `client_id` or `id_token_hint` parameter in case that `post_logout_redirect_uri` is included.
 
 If you want to avoid logging out of an external identity provider as part of the logout process, you can supply the parameter `$$initiating_idp$$`, with the value being
 the identity (alias) of the identity provider in question. This parameter is useful when the logout endpoint is invoked as part of single logout initiated by the external identity provider.

server_admin/topics/clients/oidc/con-basic-settings.adoc

@@ -44,6 +44,9 @@ If this is on, clients are allowed to use the OIDC xref:con-oidc-auth-flows_{con
 +
 Exclusive redirect URL patterns are typically more secure.  See xref:unspecific-redirect-uris_{context}[Unspecific Redirect URIs] for more information.
 
+*Valid post logout redirect URIs*:: This setting is similar to `Valid Redirect URIs`, but these URIs  are valid redirect URIs to be used for the redirect to this client after logout. Use the value `+` to use same set of URIs
+as specified by `Valid Redirect URIs` option.
+
 *Base URL*:: This URL is used when {project_name} needs to link to the client.
 
 [[_admin-url]]

server_admin/topics/sso-protocols/con-oidc-auth-flows.adoc

@@ -333,8 +333,10 @@ This redirect usually happens when the user clicks the `Log Out` link on the pag
 
 Once the user is redirected to the logout endpoint, {project_name} is going to send logout requests to
 clients to let them to invalidate their local user sessions, and potentially redirect the user to some URL
-once the logout process is finished. The user might be optionally requested to confirm the logout in case that `id_token_hint` parameter was not used
-or the client referenced in the ID Token from `id_token_hint` has `Consent Required` enabled.
+once the logout process is finished. The user might be optionally requested to confirm the logout in case the  `id_token_hint` parameter was not used.
+After logout, the user is automatically redirected to the specified `post_logout_redirect_uri` as long as it is provided as a parameter.
+Note that you need to include either the `client_id` or `id_token_hint` parameter in case the `post_logout_redirect_uri` is included. Also the `post_logout_redirect_uri` parameter
+needs to match one of the `Valid Post Logout Redirect URIs` specified in the client configuration.
 
 Depending on the client configuration, logout requests can be sent to clients through the front-channel or through the back-channel. For the frontend browser clients, which rely on the
 Session Management described in the previous section, {project_name} does not need to send any logout requests to them; these clients automatically detect that SSO session