Logout ely 2534 by rsearls · Pull Request #2249 · wildfly-security/wildfly-elytron

rsearls · 2025-01-13T21:00:08Z

https://issues.redhat.com/browse/ELY-2534

supersede #2245

pedro-hos

LGTM overall! One small improvement could be adjusting the debug message to match the format of other log statements. For instance, instead of:

log.debug("evaluateRequest uri: " + request.getRequestURI().toString());

You might consider using log.debugf for consistency:

log.debugf("The evaluated request URI is [%s]", request.getRequestURI().toString());

This keeps the style aligned with existing logs, like:

log.debugf("Ignoring request for path [%s] from mechanism [%s]. No client configuration context found." ...);

That said, this is a minor improvement — everything else looks great to me!

pedro-hos · 2025-02-27T16:28:22Z

+    private static final String POST_LOGOUT_REDIRECT_URI_PARAM = "post_logout_redirect_uri";
+    private static final String ID_TOKEN_HINT_PARAM = "id_token_hint";
+    private static final String LOGOUT_TOKEN_PARAM = "logout_token";
+    private static final String LOGOUT_TOKEN_TYPE = "Logout";


"Logout" with the first capital letter is the expected value?

Yes "Logout" is expected it looks to be a key for claim types. similarly "Bearer" is capitalized as well.

I changed the log.debug ref to log.debugf only in the code I added. I prefer to leave pre-existing code as is.

Thanks for the code review and the suggestions.

Are "logout_token" and "Logout" specific to the Keycloak OpenID provider? I'm not seeing these in the OIDC logout specs. If these are Keycloak-specific, we need to be careful to make sure we are not introducing logic that won't work for providers that don't make use of these.

That reminds me, it would also be good to do some manual tests using your built WildFly server with other OpenID providers like Auth0 or Okta to make sure things work as expected with a non-Keycloak provider.

"logout_token" is defined in the Back-Channel spec, so it is not Elytron specific.

I think the "Logout" value for the "typ" claim looks to be specific to Keycloak. @pedroigor Can you confirm?

In the Back Channel spec, I see the following:

"Another way to prevent cross-JWT confusion is to use explicit typing, as described in Section 3.11 of [RFC8725]. One would explicitly type a Logout Token by including a typ (type) Header Parameter with a value of logout+jwt (which is registered in Section 5.3.1. Note that the application/ portion of the application/logout+jwt media type name is omitted when used as a typ Header Parameter value, as described in the typ definition in Section 4.1.9 [JWS]. Including an explicit type in issued Logout Tokens is a best practice. Note however, that requiring explicitly typed Logout Tokens will break most existing deployments, as existing OPs and RPs are already commonly using untyped Logout Tokens. However, requiring explicit typing would be a good idea for new deployment profiles where compatibility with existing deployments is not a consideration."

https://openid.net/specs/openid-connect-backchannel-1_0.html#CrossJWT

pedro-hos

LGTM

fjuma · 2025-03-17T18:25:47Z

    });

    boolean tryLogout(OidcHttpFacade facade) {
+        log.trace("tryLogout entered");


Just to check, I know some of these trace and debug statements were added for debugging. Do we still want to keep all of these?

I can remove them but I think they could be very helpful debugging customer issues with logout.

Keeping ones that make sense is fine. Might be good to revisit the messages and make sure they have sufficient details/are consistent.

fjuma · 2025-03-17T18:30:46Z

        public HttpScope getScope(Scope scope) {
+            if (requestURI != null && "/clientApp/logout/callback".equals(requestURI.getPath())){
+                return null;
+            }


Why is this needed here?

This is needed to allow assertUserNotAuthenticated() after user logout to function properly.

Just wondering if this is the right place to add this logic since getScope doesn't take the requestURI as a param.

fjuma · 2025-03-17T18:35:27Z

    @Message(id = 23070, value = "Authentication request format must be one of the following: oauth2, request, request_uri.")
    RuntimeException invalidAuthenticationRequestFormat();
+
+    @Message(id = 23071, value = "%s is not a valid value for %s")


Once the nonce changes are merged, we'll need to merge the latest changes from 2.x into this branch and these message IDs will need to be updated here.

fjuma · 2025-03-17T18:39:52Z

    protected String requestObjectSigningKeyStoreType;
    protected JWKEncPublicKeyLocator encryptionPublicKeyLocator;
-    private boolean logoutSessionRequired = true;
+    private String logoutSessionRequired;


Why was this changed to a String?

This is an optional setting. We needed to be able to determine if the user specifically set the value or not.
If this was a boolean we would not be able to determine if the user set the value to true, false or not set at all.

From the analysis document, it looks like the default for this should be set to true. We should be using boolean here (we have other similar boolean attributes as well). (Note that it's also possible to use Boolean but I think that will be needed for the system property case, it shouldn't be needed here.)

fjuma · 2025-03-17T18:43:30Z

-        String tmpLogoutPath = System.getProperty(LOGOUT_PATH);
+        String tmpLogoutPath = oidcJsonConfiguration.getLogoutPath();
+        if (tmpLogoutPath == null) {
+            tmpLogoutPath = System.getProperty(LOGOUT_PATH);


The system property configuration shouldn't be part of this branch. In this 2.x branch, logout should be configured using OIDC JSON configuration only.

fjuma · 2025-03-17T18:49:30Z

In bbc858c, it looks like there are changes to tool/LICENSE.txt, there shouldn't be any changes there.

fjuma · 2025-03-17T18:52:50Z

+    public void testLogoutPath() {
+
+        try {
+            System.setProperty(Oidc.LOGOUT_PATH, " ");


System property related tests should be for the maintenance branch. They shouldn't be present in this 2.x branch.

fjuma · 2025-03-19T19:11:37Z

 /*
 * JBoss, Home of Professional Open Source.
- * Copyright 2021 Red Hat, Inc., and individual contributors
+ * Copyright 2024 Red Hat, Inc., and individual contributors


Just a minor comment, we don't need to update the year on existing files.

original date returned

fjuma · 2025-03-19T19:12:58Z

    @Message(id = 23070, value = "Authentication request format must be one of the following: oauth2, request, request_uri.")
    RuntimeException invalidAuthenticationRequestFormat();
+
+    @Message(id = 23071, value = "Invalid logout output: %s is not a valid value for %s")


Now that the OIDC nonce PR was merged, it's a good time to add a commit that merges the latest changes from 2.x and then update the message IDs.

fjuma · 2025-03-19T19:20:00Z

+        this.sessionRequiredOnLogout = sessionRequiredOnLogout;
+    }
+
+    public int getLogoutSessionWaitingLimit() {


Just thinking it might be good to rename this to make it easier to understand what it's used for.

fjuma · 2025-03-19T20:19:10Z

+            logoutUri = redirectUriBuilder.build().toString();
+            log.trace("redirectEndSessionEndpoint path: " + redirectUriBuilder.toString());
+        } catch (URISyntaxException e) {
+            throw new RuntimeException(e);


We should use ElytronMessages here.

fjuma · 2025-03-19T20:29:02Z

+        JwtClaims claims;
+
+        try {
+            claims = tokenValidator.verify(logoutToken);


As mentioned above, we need to check if this "Logout" token type is Keycloak-specific because if it is, this validation will fail for OpenID providers other an than Keycloak.

"logout_token" is defined in the Back-Channel spec, so it is not Elytron specific.

fjuma · 2025-03-19T20:30:04Z

+        }
+
+        if (!isSessionRequiredOnLogout(facade)) {
+            log.warn("Back-channel logout request received but can not infer sid from logout token to mark it for invalidation");


This should be in ElytronMessages.

fjuma · 2025-03-19T20:31:55Z

    public static final String PROVIDER_URL = "provider-url";
+    public static final String LOGOUT_PATH = "logout-path";
+    public static final String LOGOUT_CALLBACK_PATH = "logout-callback-path";
+    public static final String POST_LOGOUT_URI = "post-logout-uri";


I think the RP initiated logout spec refers to this as post_logout_redirect_uri. Any reason to not use POST_LOGOUT_REDIRECT_URI=post-logout-redirect-uri here?

This can be changed but it will required a revision to the proposal doc,
wildfly/elytron-oidc-client schema doc and corresponding code, and the
integration tests. How would you like to proceed with this?

In general, it's good to use names that are consistent with the spec so it's intuitive how things defined in the spec relate to things in our configuration. I think the original name that was used in the proposal was post-logout-redirect-uri. Do you recall why it was changed to to post-logout-uri?

fjuma · 2025-03-19T20:37:16Z

+    private String logoutPath = "/logout";
+    private String logoutCallbackPath = "/logout/callback";
+
+    private int logoutSessionWaitingLimit = 100;


Would be good to define a constant in Oidc.java for this default value.

fjuma · 2025-03-19T20:37:30Z

+    private String postLogoutUri;
+    private boolean sessionRequiredOnLogout = true;
+    private String logoutPath = "/logout";
+    private String logoutCallbackPath = "/logout/callback";


Would be good to define a constant in Oidc.java for the above two default values.

fjuma · 2025-03-19T20:38:58Z

        return tokenUrl;
    }

-    public String getLogoutUrl() {


Is this rename needed?

The value being return is the path component of a URL not the URL itself.
For accuracy and clarity the name was changed. In addition this variable
is directly related to the property name logout-path as defined in the
proposal doc and the elytron-oidc-client schema.

Sorry, I was asking about the getLogoutUrl method being renamed to getEndSessionEndpointUrl.

I see now that getEndSessionEndpointUrl wasn't part of your commits, it was actually part of Pedro's initial changes. That's fine.

fjuma · 2025-03-19T20:40:11Z

        return this.encryptionPublicKeyLocator;
    }
+
+    public void setPostLogoutUri(String postLogoutUri) {


Could we use use setPostLogoutRedirectUri(String postLogoutRedirectUri)?

Elytron's coding convention appears to be to define a get/set method name
that uses the same variable name. If we change variable postLogoutUri to
postLogoutRedirectUri as discussed in a previous comment then this method
name should change as well.

Yes, that's right, just wanted to point these references out as a reminder to myself when reviewing. Sometimes it's easy to update a variable name but forget to update some of the methods that reference it. :)

fjuma · 2025-03-19T20:40:23Z

+        this.postLogoutUri = postLogoutUri;
+    }
+
+    public String getPostLogoutUri() {


Similar comment here as the one above.

Change dependent on previous name decision as discussed above

fjuma · 2025-03-19T20:41:13Z

        oidcClientConfiguration.setTokenSignatureAlgorithm(oidcJsonConfiguration.getTokenSignatureAlgorithm());

+        String tmpLogoutPath = oidcJsonConfiguration.getLogoutPath();
+        log.debugf("sysProp LOGOUT_PATH: " + (tmpLogoutPath == null ? "NULL" : tmpLogoutPath));


This references a system property.

The special null handling isn't needed.

fjuma · 2025-03-19T20:46:41Z

+        }
+
+        String tmpLogoutCallbackPath = oidcJsonConfiguration.getLogoutCallbackPath();
+        log.debugf("sysProp LOGOUT_CALLBACK_PATH: " + (tmpLogoutCallbackPath == null ? "NULL" : tmpLogoutCallbackPath));


This should be updated, currently references sysProp.

The special null handling isn't needed.

skyllarr

@rsearls I haven't finish the review yet, just addint some in proress comments for now

skyllarr · 2025-12-08T16:18:26Z

@@ -1 +0,0 @@
-src/main/resources/META-INF/LICENSE.txt


@rsearls This file should not be altered? It contains a single line originally: https://github.com/wildfly-security/wildfly-elytron/blob/2.x/tool/LICENSE.txt

skyllarr · 2025-12-08T16:23:16Z


-    @Message(id = 23050, value = "Invalid bearer token claims")
-    OidcException invalidBearerTokenClaims();
+    @Message(id = 23050, value = "Invalid token claims")


@rsearls Can we add another message instead of changing the existing one? For some backwards compatibility in logging

switching the msg order addresses the issue.

@rsearls Can you pls clarify how this was addressed? it is just a minor, but I think that the message with ID 23050 already existed prior to this feature, so instead of editing it, we could add another message with new unique ID

@rsearls actually looking more closely, the only place where this is used is in TokenValidator. This validates both the bearer token and ID token so it might have been renamed on purpose to address both token types. Or do we know why was this renamed? Was it renamed by somebody esle in commits?

I reviewed the code history and saw this before yesterdays change.
214 @message(id = 23050, value = "Invalid bearer token claims")
215 OidcException invalidBearerTokenClaims();
214 @message(id = 23050, value = "Invalid token claims")
215 OidcException invalidTokenClaims();
The first usage, "invalidBearerTokenClaims" was replaced by "invalidTokenClaims" on 3/21/25.
This was done because the message itself was changed from a reference specifically
to "bearer token" to a more generic message; the message method naming pattern
was being followed. A method call to "invalidBearerTokenClaims" no longer exists
in the code base. Most likely the message was made more generic when an
addition of nonce handling was added. Most likely the old message was returned
when a merge of elytron 2.x was performed last week to bring this branch up to date.

@rsearls Hm when I look at the https://github.com/wildfly-security/wildfly-elytron/blame/2.x/http/oidc/src/main/java/org/wildfly/security/http/oidc/ElytronMessages.java#L215C32-L215C43 , it says that the 2.x branch has the invalidBearerTokenClaims since the bearer token support was added 3 years ago. Do you maybe have a different view locally?

The name was generalize when BackChannelLogout logoutToken
validation was added.
I think when I did the rebase of 2.x to my branch last week is when the competing messages appeared.

skyllarr · 2025-12-08T16:25:58Z

    String nonceCookieDoesNotExist();
+
+    @Message(id = 23074, value = "Invalid logout path: %s is not a valid value for %s")
+    IllegalArgumentException invalidLogoutPath(String pathValue, String pathName);


just a minor, I think this message and below message can accept a single parameter, as the logout path will be an attribute and always have a value of "logout-path" ?

@message(id = 23074, value = "Invalid logout path: %s is not a valid value for %s")

IllegalArgumentException invalidLogoutPath(String pathValue, String pathName);

For clarity for the user I think the current message should be maintained
or the message changed to "%s is not a valid value for attribute logout-path".
What is your preference?

I have removed "invalidLogoutCallbackPath" as it is not being used anywhere

@rsearls My thought was changing it to be "%s is not a valid value for attribute logout-path". Or it could also be simplified to be more generic and used in more situations:

@Message(id = 23074, value = "Invalid attribute: %s is not a valid value for %s") IllegalArgumentException invalidAttribute(String pathValue, String pathName);

But thinking more about it, since this is a preview feature, and there is a tiny possibility of the "logout-path" changing in the future, let's keep it as it is now.

Btw I can still see the "invalidLogoutCallbackPath" in these changes, so it was not removed.

I was waiting to hear your preference for the message in "invalidAttribute" before checking in the change where I removed the "invalidLogoutCallbackPath"

skyllarr · 2025-12-08T16:26:34Z

+    RuntimeException unableToCreateEndSessionEndpointRequest(String url, String msg);
+
+    @Message(id = 23077, value = "Back-channel logout request received but can not infer sid from logout token to mark it for invalidation")
+    String sidCanNotBeInferFromLogoutToken();


s/sidCanNotBeInferFromLogoutToken/sidCanNotBeInferredFromLogoutToken

skyllarr · 2025-12-08T17:57:50Z

+        if (idToken == null) {
+            return false;
+        }
+        return sessionsMarkedForInvalidation.remove(idToken.getNonce()) != null;


@rsearls We are removing the key "idToken.getNonce()" from the map. But we are putting "getSessionKey(facade, sessionId)" key there on line 209.

This doesn't have to be the same key? Shouldn't we remove the getSessionKey(facade, sessionId) value here instead?

I think this is to high risk a change at this time. I do not understand the
details of how IDToken or sessionId is used in these scenarios. I think it
would be safest to create a jira for this to be addressed in the future.

@rsearls I checked and we are the ones creating the NONCE value, send it with the initial login request to OpenID provider, and they send it back so we can validate it is the same value that we have sent. We are creating it in the OidcRequestAuthenticator here, and then we compare the received nonce in TokenValidator here. It seems you have added this code in the past so maybe you know whether my understanding is correct?

If so, how we use the map with different key being put there and different key removed seems to me like a bug, because the value of nonce will be random, but the value of getSessionKey(facade, sessionId) will be something like clientId-sessionId.

Change implemented

skyllarr · 2025-12-08T18:04:32Z

+    /**
+     * A bounded map to store sessions marked for invalidation after receiving logout requests through the back-channel
+     */
+    private Map<String, OidcClientConfiguration> sessionsMarkedForInvalidation = synchronizedMap(new LinkedHashMap<String, OidcClientConfiguration>(16, 0.75f, true) {


@rsearls Not sure if this was discussed, and it can possibly be an enhancement later. But this invalidation map will work only on the same JVM. Was there any discussion about whether it is makes sense to make it work in distributed environments?

There was never any discussion about this. I recommend we create a jira to
evaluate and address this in the future.

rsearls · 2025-12-08T21:01:51Z

In branch 2.x tool/LICENSE.txt is a link to a file. I have addressed this.

skyllarr · 2025-12-09T13:29:55Z

    }

-    public String getLogoutUrl() {
+    public String getEndSessionEndpointUrl() {


Just a note for other reviewers, http/oidc is not part of the public API so these renames are fine

skyllarr · 2025-12-09T13:59:22Z

-            return new AccessToken(jwtClaims);
        } catch (InvalidJwtException e) {
-            log.tracef("Problem parsing bearer token: " + bearerToken, e);
+            log.tracef("Problem parsing bearer token: " + token, e);


@rsearls Just wondering why the message was changed from invalidBearerTokenClaims to invalidTokenClaims and if the log here should also have "bearer" removed and be: log.tracef("Problem parsing token: " + token, e);

this relates to our other discussion above about whether we are changing this message in this PR or it was changed elsewhere already.

TokenVaidator.verify was generalized when BackChannelLogout logoutToken
validation was added.
LogoutHandler.handleBackChannelLogoutRequest
155 String logoutToken = facade.getRequest().getFirstParam(LOGOUT_TOKEN_PARAM);
from the request object a logoutToken is looked for. If present
it contains jwtClaim parseable information related to logout.
169 claims = tokenValidator.verify(logoutToken);

Token validation was no longer just for Bearer tokens.
BearerTokenRequestAuthenticator.verifyToken
99 token = tokenValidator.parseAndVerifyToken(tokenString);
Method parseAndVerifyToken calls method verify
TokenValidator.parseAndVerifyToken
125 return new AccessToken(verify(token));

There is no reason "bearer" can't be remove from the log msg at
line 151.

Is that your preference?

skyllarr · 2025-12-09T14:14:47Z

@rsearls Later today I plan to try to manually test all these logout mechanisms with keycloak locally. Just wondering if this is something you tried as well already?

skyllarr · 2025-12-09T15:26:15Z

+        try {
+            URL url = new URL(tmpLogoutCallbackPath);
+            if (uriStr.equals(url.toString())
+                || uriStr.endsWith(tmpLogoutCallbackPath)) {


The method getRelativePath() returns path that is relative to the context path of the application. So then IMO this should work: facade.getRequest().getRelativePath().equals(tmpLogoutCallbackPath)

I don't think that works in this usage. Callback path is text that can be
appended to a URL. It is text that is registered with Keycloak as the post
logout path and keycloak sends the url back on logout.

Change implemented

skyllarr · 2025-12-09T15:27:11Z

+        if (logoutPath == null) {
+            return false;
+        }
+        return path.endsWith(logoutPath);


IMO here we can also use equals instead of endsWith

Yes this is for the same reason as above.

Changing this to equals caused tests to fail.

skyllarr · 2025-12-09T15:28:37Z

+        facade.getTokenStore().logout(false);
+    }
+
+    private String getRedirectUri(OidcHttpFacade facade) {


Just a detail, this method is unused

I've removed it.

skyllarr · 2025-12-09T15:58:08Z


-    @Message(id = 23050, value = "Invalid bearer token claims")
-    OidcException invalidBearerTokenClaims();
+    @Message(id = 23050, value = "Invalid token claims")


@rsearls Hm when I look at the https://github.com/wildfly-security/wildfly-elytron/blame/2.x/http/oidc/src/main/java/org/wildfly/security/http/oidc/ElytronMessages.java#L215C32-L215C43 , it says that the 2.x branch has the invalidBearerTokenClaims since the bearer token support was added 3 years ago. Do you maybe have a different view locally?

skyllarr · 2025-12-09T16:25:12Z

+            IDToken idToken = context.getIDToken();
+            String issuer = request.getQueryParamValue(ISS);
+
+            if (idToken == null || !sessionId.equals(idToken.getNonce()) || !idToken.getIssuer().equals(issuer)) {


this is another instance of comparing sessionId (from sid query parameter) to idToken.getNonce() . Not sure why since these are different concepts it seems to me. I wonder if Keycloak configures these values to match, but other providers might not match them. we will need to investigate this

skyllarr · 2025-12-09T17:09:06Z

+    private void handleBackChannelLogoutRequest(OidcHttpFacade facade) {
+
+        OidcClientConfiguration clientConfiguration = facade.getOidcClientConfiguration();
+        String logoutToken = facade.getRequest().getFirstParam(LOGOUT_TOKEN_PARAM);


@rsearls Should we add a null check for logout token parameter here?

We could do a null check however an InvalidJwtException exception will be thrown by the TokenValidation code. There is logging in place for that.

Do you want a null check to be added to the code any way?

skyllarr · 2025-12-09T17:11:41Z

+
+        try {
+            URIBuilder redirectUriBuilder = new URIBuilder(clientConfiguration.getEndSessionEndpointUrl())
+                    .addParameter(ID_TOKEN_HINT_PARAM, securityContext.getIDTokenString());


maybe let's add a null check for securityContext.getIDTokenString() so that we do not add a parameter to the URI with null value

I've added the check.

rsearls · 2025-12-09T19:38:37Z

I have not manually tested logout recently. It was do in the past.

OndrejKotek · 2025-12-11T12:08:17Z


    @Override
    public void evaluateRequest(HttpServerRequest request) throws HttpAuthenticationException {
+        log.debugf("evaluateRequest uri: " + request.getRequestURI().toString());


Suggested change

log.debugf("evaluateRequest uri: " + request.getRequestURI().toString());

log.debugf("Evaluating request URI: [%s]", request.getRequestURI());

There are more of those. I'm not sure which are meant to stay.

There are also several debugf where debug would be sufficient instead.

All other such log msg are pre-existing. I don't think they should be changed.

OndrejKotek · 2025-12-11T13:07:11Z

+        OidcClientConfiguration clientConfiguration = facade.getOidcClientConfiguration();
+        String logoutToken = facade.getRequest().getFirstParam(LOGOUT_TOKEN_PARAM);
+        TokenValidator.Builder tokenBuilder = TokenValidator.builder(clientConfiguration)
+                .setSkipExpirationValidator();


Do I understand it correctly that we skip the Logout Token expiration validation? Is there another way to prevent captured Logout Tokens from being replayable we rely on?

I don't know. Perhaps @pedroigor or @skyllarr could comment on this.

OndrejKotek · 2025-12-11T13:22:32Z

+        String sessionId = claims.getClaimValueAsString(SID);
+
+        if (sessionId == null) {
+            facade.getResponse().setStatus(HttpStatus.SC_BAD_REQUEST);


Does this mean that we do not support logout for all sessions (at once) at the RP for the End-User identified by the iss and sub Claims? If yes, it could be useful to add the fact to the analysis document.

Perhaps @pedroigor would like to comment on this.

OndrejKotek · 2025-12-11T13:29:10Z

+
+        OidcClientConfiguration clientConfiguration = facade.getOidcClientConfiguration();
+        String logoutToken = facade.getRequest().getFirstParam(LOGOUT_TOKEN_PARAM);
+        TokenValidator.Builder tokenBuilder = TokenValidator.builder(clientConfiguration)


I cannot find events Claim content validation, and not-presence of nonce Claim validation required by the specification.

There are various types of claims validators in TokenValidator. There are several inner classes there are run for validation.

Agree. Nonetheless it seems the validation required by the specification is missing.

…ck-channel logout

…an active session

…ing doesn't rely on an active session and ensure the session will get invalidated appropriately upon subsequent requests

…validation check to before the authenticator#authenticate call and update the check to not remove the session from the map to ensure that the user gets logged out from any other apps too

… the sessionsMarkedForInvalidation map

rsearls · 2026-02-23T19:43:03Z

In preparation for a sprint. Closing this PR. Rebase branch to current 2.x and create a new PR

rsearls marked this pull request as ready for review January 13, 2025 21:25

rsearls requested review from fjuma and skyllarr as code owners January 13, 2025 21:25

rsearls mentioned this pull request Jan 13, 2025

Ely 2534 OIDC logout support #2245

Closed

rsearls force-pushed the logout-ELY-2534 branch from c66c9ab to b3ffe0f Compare January 22, 2025 14:00

rsearls force-pushed the logout-ELY-2534 branch from 1123a7f to bbc858c Compare February 25, 2025 20:06

rsearls mentioned this pull request Feb 25, 2025

[Preview][WFLY-19314] Logout support for OIDC wildfly/wildfly-proposals#687

Open

pedro-hos reviewed Feb 27, 2025

View reviewed changes

pedro-hos approved these changes Mar 11, 2025

View reviewed changes

fjuma reviewed Mar 17, 2025

View reviewed changes

fjuma reviewed Mar 19, 2025

View reviewed changes

skyllarr reviewed Dec 8, 2025

View reviewed changes

rsearls force-pushed the logout-ELY-2534 branch 2 times, most recently from 8641c40 to 91e8612 Compare December 8, 2025 19:25

skyllarr reviewed Dec 9, 2025

View reviewed changes

rsearls force-pushed the logout-ELY-2534 branch from 698cc13 to 261b914 Compare December 10, 2025 15:13

OndrejKotek reviewed Dec 11, 2025

View reviewed changes

Comment thread http/oidc/src/main/java/org/wildfly/security/http/oidc/TokenValidator.java

OndrejKotek reviewed Dec 11, 2025

View reviewed changes

pedroigor and others added 11 commits February 23, 2026 14:18

OpenID Connect Logout support

105f9ae

[ELY-2534] Update copyright headers

1c3cd34

[ELY-2534] Update the creation of the test HTTP server request for ba…

cd4bb83

…ck-channel logout

[ELY-2534] Update back-channel logout handling so it doesn't rely on …

798788f

…an active session

logout file with debug stmts

3754ad4

working code for rpinitiated logout. contains tmp debug stmts

ef5cc1f

[ELY-2534] Restore the changes made so that back-channel logout handl…

dad5a09

…ing doesn't rely on an active session and ensure the session will get invalidated appropriately upon subsequent requests

[ELY-2534] Fix back-channel logout by moving the isSessionMarkedForIn…

ea67e0c

…validation check to before the authenticator#authenticate call and update the check to not remove the session from the map to ensure that the user gets logged out from any other apps too

[ELY-2534] Use the client ID and sid from the ID token in the key for…

70a543a

… the sessionsMarkedForInvalidation map

[ELY-2534] OIDC logout support

7c73433

add check for tokenType

2afa7d6

rsearls force-pushed the logout-ELY-2534 branch from c8af440 to 2afa7d6 Compare February 23, 2026 19:36

rsearls closed this Feb 23, 2026

rsearls mentioned this pull request Feb 23, 2026

Logout ely 2534 #2411

Closed

		@@ -1 +0,0 @@
		src/main/resources/META-INF/LICENSE.txt No newline at end of file

	log.debugf("evaluateRequest uri: " + request.getRequestURI().toString());
	log.debugf("Evaluating request URI: [%s]", request.getRequestURI());

Conversation

rsearls commented Jan 13, 2025

Uh oh!

pedro-hos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pedro-hos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fjuma commented Mar 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fjuma commented Mar 17, 2025 •

edited

Loading

fjuma Mar 19, 2025 •

edited

Loading