CODEWITHSUNDEEP
identityserver3
Rob L
Rob L

Reputation: 3304

In IdentityServer3, how should you link the Claims to Token in a custom TokenHandleStore implementation?

I am implementing an IdentityServer3 application, while closely following the EntityFramework IdentityServer3 solution. However, the problem is this...

When a Token object is saved, if the Claims are not somehow linked to the Token when the Token is saved here it will inevitably result in unauthorized requests when your client calls your resource server. This happens when the Token is loaded from the database because the Claims that were originally attached to the Token are no longer existent (since they were not saved).

The in memory solution in IdentityServer3 does not have this issue because your object stays in memory, so the list of claims inside the Token object stay "attached" to the token. See here for the in memory solution.

If you don't link claims to the Token upon the save, a reference token cannot be verified when it is retrieved from the database.

I imagine you need to save the relationship between the Claims and the Token when you save the Token. However, this is problematic because at that point in the code (see here) you cannot easily and reliably determine if a Claim is a Scope Claim, Client Claim or a User claim.

How will you properly insert a record into a joining/linking table that would link the Token to the correct claims table? Since there is a ScopeClaims table, a ClientClaims table and there can be a UserClaims table... Usually the claims associated with any given Token are a mixture of Client, Scope and User claims.

What are the recommendations for handling the Token save in such a way that it will keep the claims?

Update As John pointed out, the EF solution serializes the entire Token object at save time so when the Token is queried a deserialization process occurs that re-hydrates the Claims and other fields that were in the Token. Following this approach you do not have to figure out a way to link the Claims to the Token using a join table or something similar. I initially overlooked this important functionality.

Upvotes: 0

Views: 113

Answers (1)

John Korsnes
John Korsnes

Reputation: 2275

One approach is to follow what how the EF implementation handles it - by storing the extra claims as a serialized JSON string. Since that is written by the authors of idsrv, it's also a great reference :)

Upvotes: 1

Related Questions