4

I'm able to store a user's access token for later use in my already existing database using this code:

// This works - Will use access token for API calls later.
dbIdentity.AddClaim(new Claim("GoogleAccessToken", accessToken));

The problem is that when the access token expires a new access token is retrieved from Google (which I can get the value of and read), BUT I can't find a way to update this value in the user's original claims, let alone REMOVE a claim for the user's original claims.

// This DOES NOT work. Identity error about ownership/authorization is generated.
dbIdentity.RemoveClaim(claimsIdentity.FindFirst("GoogleAccessToken"));

Error: The Claim '' was not able to be removed. It is either not part of this Identity or it is a claim that is owned by the Principal that contains this Identity. For example, the Principal will own the claim when creating a GenericPrincipal with roles. The roles will be exposed through the Identity that is passed in the constructor, but not actually owned by the Identity. Similar logic exists for a RolePrincipal.

I think the problem has something to do with logging in after the token expires 60 minutes later. I believe the scenario is that the "now logged-in identity with newly generated access token" isn't linked to the "original identity with the old access token", so it doesn't let me update the user's original claims. The identities and principals are not the same.

Is it possible to link up the identities or update the claims another (easier) way? How can I accomplish that? Please help, thanks.

2 Answers2

1

See if this works https://stackoverflow.com/a/24591892/4651116

More underneath has an extension code, look

Community
  • 1
  • 1
  • I copied the extension methods but they do not work. It errors on line "var claims = userManager.GetClaims(user.Id); which is inside function RemoveClaim();". It returns null. The user's claims definitely exist though because I can see them in the AspNetUserClaims table. – ForeverLearningAndCoding Aug 16 '16 at 21:08
0

Used a workaround instead. When all else fails you can just query and update the database manually!

BLAH to "unwanted" workarounds...