Skip to content

Fix OIDC Logout docs: Session Strategy vs. Registry #15686

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -650,7 +650,7 @@ public void logoutWhenUsingOidcLogoutHandlerThenRedirects() throws Exception {
}

@Test
public void configureWhenOidcSessionStrategyThenUses() {
public void configureWhenOidcSessionRegistryThenUses() {
this.spring.register(OAuth2LoginWithOidcSessionRegistry.class).autowire();
OidcSessionRegistry registry = this.spring.getContext().getBean(OidcSessionRegistry.class);
this.spring.getContext().publishEvent(new HttpSessionDestroyedEvent(this.request.getSession()));
Expand Down
18 changes: 9 additions & 9 deletions docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.

The overall flow for a Back-Channel logout is like this:

1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionStrategy` implementation.
1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `ReactiveOidcSessionRegistry` implementation.
2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
3. Spring Security validates the token's signature and claims.
4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
Expand All @@ -197,13 +197,13 @@ The overall flow for a Back-Channel logout is like this:
Remember that Spring Security's OIDC support is multi-tenant.
This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.

=== Customizing the OIDC Provider Session Strategy
=== Customizing the OIDC Provider Session Registry

By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.

There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.

You can achieve this by configuring a custom `ReactiveOidcSessionStrategy`, like so:
You can achieve this by configuring a custom `ReactiveOidcSessionRegistry`, like so:

[tabs]
======
Expand All @@ -212,23 +212,23 @@ Java::
[source,java,role="primary"]
----
@Component
public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy {
public final class MySpringDataOidcSessionRegistry implements ReactiveOidcSessionRegistry {
private final OidcProviderSessionRepository sessions;

// ...

@Override
public void saveSessionInformation(OidcSessionInformation info) {
this.sessions.save(info);
public Mono<void> saveSessionInformation(OidcSessionInformation info) {
return this.sessions.save(info);
}

@Override
public OidcSessionInformation(String clientSessionId) {
public Mono<OidcSessionInformation> removeSessionInformation(String clientSessionId) {
return this.sessions.removeByClientSessionId(clientSessionId);
}

@Override
public Iterable<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) {
public Flux<OidcSessionInformation> removeSessionInformation(OidcLogoutToken token) {
return token.getSessionId() != null ?
this.sessions.removeBySessionIdAndIssuerAndAudience(...) :
this.sessions.removeBySubjectAndIssuerAndAudience(...);
Expand All @@ -241,7 +241,7 @@ Kotlin::
[source,kotlin,role="secondary"]
----
@Component
class MySpringDataOidcSessionStrategy: ReactiveOidcSessionStrategy {
class MySpringDataOidcSessionRegistry: ReactiveOidcSessionRegistry {
val sessions: OidcProviderSessionRepository

// ...
Expand Down
12 changes: 6 additions & 6 deletions docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -213,7 +213,7 @@ Consider a `ClientRegistration` whose identifier is `registrationId`.

The overall flow for a Back-Channel logout is like this:

1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionStrategy` implementation.
1. At login time, Spring Security correlates the ID Token, CSRF Token, and Provider Session ID (if any) to your application's session id in its `OidcSessionRegistry` implementation.
2. Then at logout time, your OIDC Provider makes an API call to `/logout/connect/back-channel/registrationId` including a Logout Token that indicates either the `sub` (the End User) or the `sid` (the Provider Session ID) to logout.
3. Spring Security validates the token's signature and claims.
4. If the token contains a `sid` claim, then only the Client's session that correlates to that provider session is terminated.
Expand All @@ -223,13 +223,13 @@ The overall flow for a Back-Channel logout is like this:
Remember that Spring Security's OIDC support is multi-tenant.
This means that it will only terminate sessions whose Client matches the `aud` claim in the Logout Token.

=== Customizing the OIDC Provider Session Strategy
=== Customizing the OIDC Provider Session Registry

By default, Spring Security stores in-memory all links between the OIDC Provider session and the Client session.

There are a number of circumstances, like a clustered application, where it would be nice to store this instead in a separate location, like a database.

You can achieve this by configuring a custom `OidcSessionStrategy`, like so:
You can achieve this by configuring a custom `OidcSessionRegistry`, like so:

[tabs]
======
Expand All @@ -238,7 +238,7 @@ Java::
[source,java,role="primary"]
----
@Component
public final class MySpringDataOidcSessionStrategy implements OidcSessionStrategy {
public final class MySpringDataOidcSessionRegistry implements OidcSessionRegistry {
private final OidcProviderSessionRepository sessions;

// ...
Expand All @@ -249,7 +249,7 @@ public final class MySpringDataOidcSessionStrategy implements OidcSessionStrateg
}

@Override
public OidcSessionInformation(String clientSessionId) {
public OidcSessionInformation removeSessionInformation(String clientSessionId) {
return this.sessions.removeByClientSessionId(clientSessionId);
}

Expand All @@ -267,7 +267,7 @@ Kotlin::
[source,kotlin,role="secondary"]
----
@Component
class MySpringDataOidcSessionStrategy: OidcSessionStrategy {
class MySpringDataOidcSessionRegistry: OidcSessionRegistry {
val sessions: OidcProviderSessionRepository

// ...
Expand Down