CookieAuthenticationEvents.ValidatePrincipal token revocation after back-channel logout

[promim]

Hi all!

As mentioned in my previous post, we are considering implementing server-side sessions in our setup. After going through the samples (DuendeSamples/SessionManagement), lots of questions got spawned naturally.

One of these is the "todo" comment from within the sample in CookieAuthenticationEvents.ValidatePrincipal (CookieEventHandler override):

public class CookieEventHandler : CookieAuthenticationEvents
{
    public CookieEventHandler(LogoutSessionManager logoutSessions)
    {
        LogoutSessions = logoutSessions;
    }

    public LogoutSessionManager LogoutSessions { get; }

    public override async Task ValidatePrincipal(CookieValidatePrincipalContext context)
    {
        if (context.Principal.Identity.IsAuthenticated)
        {
            var sub = context.Principal.FindFirst("sub")?.Value;
            var sid = context.Principal.FindFirst("sid")?.Value;

            if (LogoutSessions.IsLoggedOut(sub, sid))
            {
                context.RejectPrincipal();
                await context.HttpContext.SignOutAsync();

                // todo: if we have a refresh token, it should be revoked here.
            }
        }
    }
}

Can we talk about "if we have a refresh token, it should be revoked here" in the context of a setup that uses server-side sessions?

Documentation suggests the following:

CoordinateLifetimeWithUserSession (added in v6.1)
When enabled, the client’s token lifetimes (e.g. refresh tokens) will be tied to the user’s session lifetime. This means when the user logs out, any revokable tokens will be removed. If using server-side sessions, expired sessions will also remove any revokable tokens, and backchannel logout will be triggered. This client’s setting overrides the global CoordinateTokensWithUserSession configuration setting.

https://docs.duendesoftware.com/identityserver/reference/models/client/?authentication--session-management#authentication--session-management

Do we still need to initiate refresh token revocation at this point from the client application, or is that taken care of by the coordination service within the IdentityServer?

What about reference tokens (revokable access tokens)? Do I still need to initiate token revocation for the reference token? In my setup, I have a ICustomTokenRequestValidator implementation that bundles a reference token together with the JWT on /connect/token response, using ITokenResponseGenerator:

context.Result.ValidatedRequest.AccessTokenType = AccessTokenType.Reference;

var response = await generator.ProcessAsync(context.Result);

context.Result.CustomResponse = new Dictionary<string, object> { { ReferenceToken, response.AccessToken } };

At the client, I'm saving it together with the JWT so I can access it via HttpContext when I need to call APIs with a reference token.

options.Events.OnTokenResponseReceived = context =>
{
    if (context.TokenEndpointResponse.Parameters.TryGetValue("reference_token", out var referenceToken) is true
        && context.Properties is not null)
    {
        context.Properties.Items["reference_token"] = referenceToken;
    }

    return Task.CompletedTask;
};

options.Events.OnTicketReceived = context =>
{
    if (context.Properties is not null)
    {
        var tokens = context.Properties.GetTokens().ToList();

        if (context.Properties.Items.TryGetValue("reference_token", out var referenceToken)
            && !string.IsNullOrWhiteSpace(referenceToken))
        {
            tokens.Add(new() { Name = "reference_token", Value = referenceToken });
            context.Properties.StoreTokens(tokens);
        }
    }

    return Task.CompletedTask;
};

[wcabus]

The DefaultSessionCoordinationService will clean up both refresh and reference tokens (and pending authorization code or CIBA requests) from the persisted grants store when lifetime coordination is enabled as you mentioned.

Lifetime coordination can be enabled globally using the CoordinateClientLifetimesWithUserSession property, or on a per-client level by setting the CoordinateLifetimeWithUserSession property on a client to true.

That said, revoking the refresh token manually from within the CookieEventHandler in the sample or in the OnSigningOut event is still a good practice:

• If there's nothing to revoke, then this will be a no-op.
• If the DefaultSessionCoordinationService for some reason failed to clean up the refresh token, it will still be revoked when signing out.

[promim]

Thanks for the reply.

Why would the DefaultSessionCoordinationService fail to clean up the revokable tokens? Can you give some examples?

[wcabus]

The persisted grant store can have some issues when querying or deleting a bunch of records because this table contains a lot of data. Sometimes, the operation can time out, or there could be a concurrency issue if multiple instances of IdentityServer attempt to update/remove the same records simultaneously.