If we have an independent dotnet core web api in which we can validate the JWT, what would be the best approach to persist a custom piece of metadata for the session? I want to be able to embed either a Session Id within the Identity Claims which can then be used extract further data from a cache/ Alternatively the creation of a custom claim on user selection post login but I suspect this would not be feasible through Auth0 rules.
Are there any routes back into Auth0 to be able to manipulate the claims within a session?
Many Thanks
You can add custom claims to a JWT within Rule - this happens after a successful authentication but before returning the tokens back to the client applications via callback.
I’m not sure though what you mean with “on user selection post login”. What kind of user selection? The user is known when he’s authenticated.
You can’t modify that JWT afterwards though i.e. from within your application. That JWT is signed by the authorization server / Auth0. If you need to add additional information, you’d need to get a new JWT in the same way that you got the first one - going through the Rule, adding additional info to a new JWT, etc.
However, it doesn’t really sound to me that this is something that Auth0 as the Authorization server should be involved but something to handle between your client application and API directly (in other words: why does it need to be inside the JWT)? The SessionID you mention already exists prior the the user login, right? Why not just use session cookies?
The overall use case or flow is not yet clear to me, from a pure business logic perspective. Is it this kind of scenario where (just an example) an anonymous user shops on an e-commerce website and just later in the cycle logs in, and you then want to be able to track that user and assign the filled shopping cart back to this now authenticated user?