How to request an identity token after the sign-in dance

[merijndejonge]

During a login, my client receives an id_token, an access_token, and a refresh_token, as described at https://docs.duendesoftware.com/identityserver/v6/tokens/requesting/.

With the refresh_token my client can fetch a new access_token.

Is there a way to retrieve an id_token as well, such that my client doesn't need to memorize it?

[josephdecock]

The response from the token endpoint should already include a new id_token. However, it isn't clear to me what purpose you intend for this id_token. Your application already used it to start its own session, and any additional identity resource claims would be retrieved from the userinfo endpoint and not included in the id_token.

[merijndejonge]

Some of the claims that are created during sign-in are supposed not to be stored for security reasons. They are calculated during sign-in and then added to the id-token. Currently we store them in the client but that is suboptimal. Since the claims are in the id-token initially, I was wondering why they are no longer in the the id-token that is returned by a token refresh.

[josephdecock]

Are you certain that the claims are different in the initial id_token and the one you get from refresh? Is it possible that the claims are actually coming from the userinfo endpoint? Your client might be making the userinfo endpoint request and adding claims to the identity automatically. How are you adding the claims to your id_token?

[josephdecock]

Any update here? Can we close this?

[merijndejonge]

I'm still a bit puzzled. My issue was fixed by adding the following

.AddCookie(CookieAuthenticationDefaults.AuthenticationScheme)

Now, after refresh, the id-token still contains all claims. This is exactly what we need.

The reason that I'm still puzzled is that with this cookie, we can use multiple identities from within our client. This means that multiple sessions are supported, while earlier posts (e.g. #594) suggest differently.

[josephdecock]

The BFF doesn't support multiple identities in the sense that there's no built-in api or endpoint for managing multiple identities, and the framework assumes that you have a single identity.

To give one example, when backchannel logout occurs, the bff can invalidate the server side session data associated with the current session of the current user. If there are multiple current users, I don't know how that would work, and it isn't something the BFF was designed for.

[merijndejonge]

Are you open to discuss the ins and out of this in this thread or offline in any form? Would like to understand better and possibly help

[josephdecock]

Helping users understand better is always the goal - do you have some particular question in mind?

[merijndejonge]

I want to better understand what the issues with sign-out in the context of multiple sessions are. We are building a multi-identity product where switching between identities is a key feature. It remains pretty unsatisfactorily that there is decent sign-out feature. When we better understand the issues we might find an alternative/workaround and/or might want to contribute in any way.

[josephdecock]

The issue is that the BFF is designed to use the Microsoft cookie authentication handler to do session management, and that session doesn't have a way to describe multiple identities. So, the BFF inherits that single identity understanding of a session.

The same is true for IdentityServer - your IdentityServer session is maintained with the same handler, which gives you the same limitations.

And on a more fundamental level, there's isn't a standardized way of representing and managing multiple identities in OpenID Connect. This raises quite a few architectural questions. I brought up the logout piece as a single example, but really there are questions in many parts of the protocol, including sign-on, session management, front channel logout and backchannel logout.

The issue with logout that I brought up is that, on signout, identity server can send backchannel logout notifications in the form of a logout token. That token will include a sub and a sid claim to identify the subject and session that is signing out, and the BFF can use server side sessions at the BFF to automatically manage that for you. However, if you have customized the session managment to track multiple identities, the BFF will not know about that.

[merijndejonge]

On top of the Microsoft cookie authentication handler extension points I've created my own session cookie that holds a collection of authentication tickets, one for each session. This collection of sessions gets updated by sign-in/sign-out events triggered by the cookie authentication handler. It seems fairly easy to use this to keep track of sessions.

Not sure about all the use cases you mention (I'm really no expert on OIDC etc), but it seems to me that as long there is a sub/sid available, it must be possible update the authentication tickets in this cookie for different sign-out/sign-in scenario's.

But I guess I miss the big picture...

[josephdecock]

I'm closing this issue, but feel free to re-open if you have a follow-up question.

[merijndejonge]

Could you be so kind to react/reflect on my post about making use of Microsoft cookie authentication handler extension points to create an alternative session cookie that can hold a collection of authentication tickets. I would like to learn/understand why this approach would not work and/or what the limitations of this are.

[brockallen]

Hi @merijndejonge. Nothing off the top of my head says that it will or won't work -- I think the devil is in the details, and it's likely worth you making an attempt at it. You will likely discover the answer to your question while prototyping, and so I'm not sure our support here is the right venue for helping your solve a project specific task like this. We do offer consulting which allow us to dig into those level of details for you, but, as I mentioned, this support channel isn't really the right place for that. Thanks.

[merijndejonge]

ok. thanks!