Customize UserToken in IUserTokenStore type

[alefcarlos]

Is there any possibility to change IUserTokenStore to be generic?

/// <summary>
/// Storage abstraction for access and refresh tokens
/// </summary>
public interface IUserTokenStore<TUserToken>
{
    Task StoreTokenAsync(
        ClaimsPrincipal user,
        TUserToken token, 
        UserTokenRequestParameters? parameters = null);
}

It adds the flexibility to adapt for any user data structure customization.

[maartenba]

Thanks for suggesting! Such change would make data migrations less predictable overall.

If they want to do something custom here in the current implementation, you can do so in your custom code (but obviously will need casting at the call site).

Going to leave this one open though in case others want to upvote.

[AndersAbel]

Could you please provide some more background for this request? What is the use case?

The way I see it, the IUserTokenStore is an interface that is defined based on what our library requires from a store. It is then up to the store implementation how to handle that. If you want to create a store that has more properties on the items, that can be done in the implementation. But to our code that uses/calls the IUserTokenStore that is an implementation detail. Our code only knows about the data type in the contract, the UserToken.

[AndersAbel]

Thanks for the additional information. Adding the IdToken to the UserToken is something that has been requested in the past too.

Please see DuendeSoftware/foss#53 is that the same thing that you want to do?

[alefcarlos]

It was exaclty that! I am also using 3dr party server with OpenId and using Duende.AccessTokenManagement to manage user session with Blazor Server. But I found out that the signout accepts the access_token, so it was solved now!

Now I'm trying to solve a PAR request error that only occurs on Release, I'm searching for an existing issue otherwise I will create another one.

[AndersAbel]

If the signout accepts the access token I think you should report that as a security issue to the provider you are using. The idea of having using the id_token is that it is something that only the client should ever have access to. The access token on the other hand is expected to be sent to APIs that are potentially only partially trusted. If the OpenId Provider access an access token as the id_token_hint, any API that gets the access token can initiate a logout.

[alefcarlos]

I will validate if the signout is really working with access_token, I'm using Keycloak.

[alefcarlos]

@AndersAbel, it was a false-positive scenario. In my OidcEvent type I wrote:

    public override async Task RedirectToIdentityProviderForSignOut(RedirectContext context)
    {
        var user = await _userAccessor.GetCurrentUserAsync();
        var token = await _store.GetTokenAsync(user);
        context.ProtocolMessage.AccessToken = token.AccessToken;
        await _service.RevokeRefreshTokenAsync(user);
    }

And the session was signout on the keycloak, but reading the OpenIdConnectHandler code it sets idToken before calling the callback.