How Can I Update my BFF Claims Without Re-Signing In

[CrossBound]

BFF version

2.x

.NET version

8.x

Description

I have a mobile client and web client that work with my IdentityServer. The mobile client is a normal native app that uses the access token to access a backend API, but my web client uses the BFF framework to interact with the IdentityServer. I have a requirement to add a claim to the user's session after they have already logged in, so it would not be issued during sign-in, but later they can trigger an action that adds the claim. I believe I can accomplish this by using a custom extension grant on the IdentityServer that does a token exchange where they pass in their current access token, plus some additional values, and get back a new access token with the claim in it (as described here Token Exchange ). This should work fine for mobile, since any future calls to the API will use the new access token and thus will have the claim available in the API.

For my BFF host, however, I'm not sure how to get the new claims available to the BFF framework. It appears from the documentation that the BFF framework relies on the userinfo endpoint to retrieve claims rather than reading them from the access token or ID token. The problem is, since the claim will only exist in the new access token (and not on their ID server session, since it wasn't added during login), I don't know how to get the BFF host to "see" the new claim.

I also considered adding it to their IdentityServer session (I'm using server-side sessions on the IdentityServer as well), but I don't know how to add a claim to the IdentityServer session after login without having to force the customer to re-login again. From what I can tell, the ticket in the server-side session is static and doesn't change once the user is logged in.

Any suggestions for solving this?

Reproduction steps

n/a

Expected behavior

I would like to be able to tell the BFF server to refresh it's claims using the ID token instead of forcing it to re-call the userinfo endpoint.

Logs

n/a

Additional context

I'm using IdentityServer V7 and BFF V2. I am using server-side sessions on both the IdentityServer and the BFF Host.

[RolandGuijt]

I'm sorry, but I can't quite follow what the problem is.

Do I understand correctly:

• The BFF gets an access token with certain user claims
• You want to add a claim after it is issued

If this is correct, can you please explain how this problem relates to the id token and session?

[CrossBound]

Yes, you are correct. The way it relates to the session is the BFF framework uses the userinfo endpoint to retrieve it's claims (and thus build it's "user") instead of pulling from the access token. The userinfo endpoint reads it's claims from the IdentityServer server-side session and not the access token. I have successfully been able to add a claim to the access token by using the token exchange method, but since this only adds a claim to the token and not to the IdentityServer server-side session, this claim is not returned in the userinfo endpoint, and thus BFF does not see the claim even though it is in the access token.

I assume this could be solved by adding a claim to the IdentityServer server-side session, but I don't know how to do that.

So my question could be boiled down to: How can I add a claim to the IdentityServer's server-side session OR, if that's not possible, how do I force BFF to read it's claims from the token instead of the userinfo endpoint?

[RolandGuijt]

The claims in the access token are separate from those in the session. So if access token exchange is used to add claims to the access token you won't find them in the session. If you want to add the claim to the session as well you'll have to sign in the user again.

[CrossBound]

@RolandGuijt That is what I was finding as well, and it sounds like from what you are saying it is not possible to add a claim to a session without requiring re-login.

Since that is the case, is it possible to configure BFF to read claims from the token instead of from the userinfo endpoint?

[RolandGuijt]

The BFF returns the sessions from the /user endpoint. It reflects the contents of the session cookie but you can add claims by using claim actions and/or claim transformations. There is more information behind the above link.
The access token shouldn't be read by a client at all. It is meant for the API and a client is just allowed to store it until it is time to access it.

[CrossBound]

I completely agree that the client shouldn't look at the access token, but it doesn't sound like I have a lot of options based on what you are saying.

[AndersAbel]

If I get this right, the new claim is available to IdentityServer, but only after the IdentityServer session was created. Now you want the new claim to be visible to the BFF client?

I would like to give a bit of background on how the IdentityServer session relates to the claims available on the user info endpoint of IdentityServer and to the token factory internally in IdentityServer. The main purpose of the IdentityServer session is to provide the claims required to show the IdentityServer UI.

The user info endpoint and the token factories also need access to the claims of the user. They get those from the profile service. The profile service can interact with a database or external APIs to supply claims. Now, there's a twist to this - IdentityServer does not ship with a user store, there might not even be one. So if there is no store to load claims of the user from, how to implement the profile service? The DefaultProfileService solves this by using the IdentityServer session.

I don't know how to add a claim to the IdentityServer session after login

If this new claim is not needed for the IdentityServer UI, there is no need to do that¹. My recommendation is to implement a custom IProfileService that can expose the new dynamic claim when it is available. That would make the claim available to the user info endpoint and to the tokens, without having to use token exchange.

For your existing native app, there is an additional setting needed. When an access token is refreshed, the default is to just copy the claims from the expired access token. To override that and cause the profile service to be invoked, set the UpdateAccessTokenClaimsOnRefresh flag on the client.

For your BFF app, there might be another step required. If your BFF app signin happens after the extra claim is made available on the profile service it will just work. If the BFF app creates the BFF session before that claim is available, the BFF needs to refresh the session to get the extra claim. Please let me know if that is the case and I'll extend the answer.

Footnotes

1. If you really need to add claims, you can do so by calling HttpContext.SignInAsync() with the updated ClaimsPrincipal and the existing AuthenticationProperties ↩

[CrossBound]

@AndersAbel thank you for the detailed reply. The BFF session is created before the claim is available, which is part of my difficulty, since I need to add the claim to an already established BFF session.

[AndersAbel]

Ok, here's the extended answer as promised:

First of all I would like to point out that any information that is changed throughout the session is not a good candidate to be a claim. Claims should be fairly static data, although they may change from time to time. Examples of typical claims are name, email, and group memberships or role assignments. All of those might change (name might be changed after marriage/divorce and that also affects email), but
not for every login and certainly not during the lifetime of the session. My first recommendation would be to review if this value really should be a claim or handled in another way.

However, I do understand that there might be reasons to store this as a claim, so I'll outline a solution on what you need to do:

1. Call the user info endpoint on IdentityServer to get the new claims.
2. Call HttpContext.SignInAsync to update the BFF session with the new claims. When doing that it is important to keep the same AuthenticationProperties so first call HttpContext.AuthenticateAsync to get the current AuthenticationTicket, then create a new ClaimsPrincipal based on the response from the user info endpoint and finally call HttpContext.SignInAsync to update the session. The new claims will now be visible on the BFF user endpoint.