Back-Channel Logout should use localhost for internal logout request

[ch4mpy]

Describe the bug
Given I have:

• a Spring OAuth2 client configured with Back-Channel Logout
• an authorization server with Back-Channel Logout configured to call the Spring OAuth2 client

When I try to visit a path requiring to be authorized on the Spring client, then I am redirected to login.

Once authenticated, I can access the protected resource.

When I visit the end_session_endpoint of the authorization server, then I can see a TRACE log on the Spring client displaying: Found and removed 1 session(s) from mapping of 1 session(s)

However, if I refresh the tab pointing to the protected resource, I can still access it.

There are two log lines after the one stating that the session was removed:

ExchangeFunctions : [1c75356f] HTTP POST http://host.docker.internal:7080/logout, headers={masked}
ExchangeFunctions : [1c75356f] Cancel signal (to close connection)

Is the client trying to call its own /logout endpoint but using the wrong hostname? host.docker.internal is the hostname used by the authorization server to initiate the Back-Channel Logout (which is running in Docker), but this hostname is unknown from the Spring client.

Expected behavior
If the Spring client needs to call itself to actually destroy the user session, shouldn't it call localhost?

Sample

https://github.com/ch4mpy/spring-security-14553

run docker compose up to create a new Keycloak instance (admin / admin to access http://localhost:8080/realms/master)

create a new realm by importing spring-security-realm.json

create a user

start the spring boot app

visit http://localhost:7080/

the end_session_endpoint is at http://localhost:8080/realms/spring-security/protocol/openid-connect/logout

[jzheaux]

@ch4mpy, good observation. I think we can change this:

String logout = UriComponentsBuilder.fromHttpUrl(url)
			.replacePath(this.logoutEndpointName)
			.build()
			.toUriString();

to:

String logout = UriComponentsBuilder.fromHttpUrl(url)
+			.host("localhost")
			.replacePath(this.logoutEndpointName)
			.build()
			.toUriString();

to address the issue.

[ch4mpy]

@jzheaux thank you.

[jk-tagbangers]

In the production environment, the logout endpoint is accessed via https.
With the current implementation, requests to https://localhost will fail due to a different default port.

e.g. https://example.com/logout/connect/back-channel/my-registration -> https://localhost/logout

So it seems like you need to change the schema and port to your own values.

Or rewrite hostname to localhost only host.docker.internal.

[lmorocz]

@jzheaux

Rewriting only the host name to localhost is not correct when the app (client) is behind a reverse proxy with TLS termination. In this case schema (HTTPS vs. HTTP) and/or port number is often different for localhost and the original hostname, as @koyama-tagbangers mentioned earlier.

The application context-path is another thing to consider here, see #14181.

One could use the internal host name/address and port number of the client in the server backchannel logout configuration, but only if the IDP (e.g. Keycloak) can access these internal hosts at all, which is often not possible.

Could we replace the POST request for the local logout resource (LogoutFilter) with something else?

[ch4mpy]

One could use the internal host name/address and port number of the client in the server backchannel logout configuration, but only if the IDP (e.g. Keycloak) can access these internal hosts at all

I think this is a wrong assumption: a server should always be able to call itself with its internal scheme, host and port. The idea here was not to modify the hostname to which the OP sends the requests, just to change what the RP uses to call itself after it received the Back-Channel Logout request. Also, the path used for this additional call(s) is not the one of the Back-Channel Logout endpoint, it is the path of the RP "standard" logout.

Note that in the case of a reverse proxy rewriting the path the previous impl could be broken too: if the request goes through the reverse proxy, the logoutEndpointName (set around line 118 of OidcBackChannel(Server)LogoutHandler) can be altered and the request fail.

Sure that if one finds a way to perform the logout without this second network call, that would eliminate the problem, but I think it was discussed in another ticket already (couldn't remember which one).

Updating the scheme, port and context path with the values we see in the logs after startup (Tomcat started on port 8080 (https) with context path '') would improve the situation, but what if the /logout endpoint is configured to something non-standard? Maybe should we just make this other "internal" logout endpoint entirely configurable?

@jzheaux maybe would it be worth to:

• rollback the modification I asked in this ticket (my use-case is certainly less frequent in prod than having the OP call the RP through a reverse proxy with a different scheme or port). An alternative being to keep localhost, but to also set scheme, port and context path (this would probably be a better default in the case of path rewriting between a reverse proxy and the OAuth2 client, but is more work).
• on the OidcBackChannelServerLogoutHandler, make all of the logout endpoint URI configurable (not only the path)
• open a bit the BackChannelLogoutConfigurer to give a hand on the OidcBackChannelServerLogoutHandler (for now, everything in BackChannelLogoutConfigurer is private, which makes it a relatively useless configurer)

Should I propose a PR for that ?

[kmeyer-mbs]

I just ran into the problem with "localhost". I use a let's encrypt SSL certificate directly in the embedded Tomcat in the local development environment. Due to the host name localhost the handshake fails.

2024-02-29T18:09:35.256+01:00 DEBUG 37790 --- [nio-7443-exec-4] c.a.w.c.o.c.OidcBackChannelLogoutHandler : Failed to invalidate session

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://localhost:7443/logout": No subject alternative DNS name matching localhost found.
	at org.springframework.web.client.RestTemplate.createResourceAccessException(RestTemplate.java:915) ~[spring-web-6.1.4.jar:6.1.4]
...

I would also welcome a configuration option.

Many thanks and best regards!