CookieAuthenticationEvents.ValidatePrincipal revocation of refresh tokens

[janssensjeroen]

I want to add some extra validation on the cookie authentication for the authorize endpoint: when certain conditions are met I want to logout the user from the IdentityServer. To achieve this, I can implement CookieAuthenticationEvents.ValidatePrincipal:

public class CookieEventHandler : CookieAuthenticationEvents
{
    public override async Task ValidatePrincipal(CookieValidatePrincipalContext context)
    {
        if (context.Principal.IsAuthenticated() && context.Request.Path == $"/{IdentityServerConstants.ProtocolRoutePaths.Authorize}")
        {
            if (CheckCondition())
            {
                context.RejectPrincipal();
                await context.HttpContext.SignOutAsync();
            }
        }
    }

    private bool CheckCondition()
    {
        throw new NotImplementedException();
    }
}

This will actually logout the user but the refresh tokens associated with the session are not revoked and are still in the database, however I enabled the CoordinateClientLifetimesWithUserSession on IdentityServer level.

I tried to understand how it works:

1. context.HttpContext.SignOutAsync() will call IdentityServerAuthenticationService.SignOutAsync() which will call context.SetSignOutCalled() that will add an item in the HttpContext
2. the IdentityServerMiddleware will then kick in and checks whether the item exists in the HttpContext (cfr context.GetSignOutCalled())
3. if that is the case, the UserSession is fetched and if it exists the DefaultSessionCoordinationService.ProcessLogoutAsync() is called which will then remove the refresh tokens from the IPersistedGrantStore

But I think the UserSession in step 3 does not exist (anymore), so the DefaultSessionCoordinationService.ProcessLogoutAsync() is not called.

Is my analysis correct and how can I ensure the refresh tokens are revoked?

[wcabus]

Since you're calling context.RejectPrincipal(); in the ValidatePrincipal method, the end result of the underlying AuthenticateAsync call will have no ClaimsPrincipal available when the current user is being retrieved from the IUserSession service.

We're wondering what the use case is behind what you're trying to achieve, because there may be better suited places to check the specific condition and rejecting the user or access to the /authorize endpoint.

One specific way would be to implement a custom authorize request validator, where you can reject the authorize request based on your conditions, and still decide to call SignOutAsync when necessary.

We also have an IProfileService which exposes the IsActiveAsync method. You could implement a custom version of this service to indicate that the current user should no longer be considered to be active.

[janssensjeroen]

Hi @wcabus, thank you for your reply.

We recently had a security audit. One of the proposed actions was to tie the session to the user's IP address. In case the user uses the /authorize endpoint with an IP address different from the IP address for which the session was started, we want to logout the user. To achieve this, we store the initial IP address in the session cookie.

You suggest to use a custom authorization request validator. Do you mean I can just inject the IHttpContextAccessor to call the SignoutAsync on the HttpContext?

[wcabus]

You can indeed inject IHttpContextAccessor inside a transient service like the custom authorization request validator. But to be safe, do not expect _httpContextAccessor.HttpContext to always return an instance. While it should always resolve during the validation of an authorize request, in can still be null in theory.

[janssensjeroen]

Ok thank you, that did the trick