IdentityServer3.EntityFramework | EntityFramework persistence layer | Identity Management library

I have used IdentityServer3.EntityFramework library to keep all configuration in SQL database. Also I'm using IdentityServer3.AspNetIdentity plugin for identity management. I can't find out how to link / map these 2 database together. I mean base on which concepts. Do I need to have UserId in Config database or should I match user claims with config claims ?

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.