diff --git a/config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java b/config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java
index d85637961d..b56d047a5f 100644
--- a/config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java
+++ b/config/src/test/java/org/springframework/security/config/annotation/web/configurers/oauth2/client/OAuth2LoginConfigurerTests.java
@@ -650,7 +650,7 @@ public class OAuth2LoginConfigurerTests {
 	}
 
 	@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()));
diff --git a/docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc b/docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc
index 4043bc3fde..c1545aeb74 100644
--- a/docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc
+++ b/docs/modules/ROOT/pages/reactive/oauth2/login/logout.adoc
@@ -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.
@@ -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]
 ======
@@ -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(...);
@@ -241,7 +241,7 @@ Kotlin::
 [source,kotlin,role="secondary"]
 ----
 @Component
-class MySpringDataOidcSessionStrategy: ReactiveOidcSessionStrategy {
+class MySpringDataOidcSessionRegistry: ReactiveOidcSessionRegistry {
     val sessions: OidcProviderSessionRepository
 
     // ...
diff --git a/docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc b/docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc
index db861486f7..32577615ed 100644
--- a/docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc
+++ b/docs/modules/ROOT/pages/servlet/oauth2/login/logout.adoc
@@ -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.
@@ -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]
 ======
@@ -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;
 
     // ...
@@ -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);
     }
 
@@ -267,7 +267,7 @@ Kotlin::
 [source,kotlin,role="secondary"]
 ----
 @Component
-class MySpringDataOidcSessionStrategy: OidcSessionStrategy {
+class MySpringDataOidcSessionRegistry: OidcSessionRegistry {
     val sessions: OidcProviderSessionRepository
 
     // ...