Is it safe to store an access_token in a user claim for authorization?

Question

So, I was having trouble with Bearer authentication while setting up IdentityServer4. Basically, I wasn't able to call my API resource and was getting a 401 error. When I added the Authorization header with the access_token. I was able to get the data from my web request.

using (var client = new HttpClient())
{
        client.DefaultRequestHeaders.Authorization = new 
           AuthenticationHeaderValue("Bearer", authToken);
        var content = await  
          client.GetStringAsync("http://localhost:5000/localapi");
}

The way I got at the auth_token was to store in a user claim that from the SecurityTokenValidated callback proved by the idenity server client setup.

Notifications = new OpenIdConnectAuthenticationNotifications
{
    SecurityTokenValidated = notification =>
    {
        var identity = notification.AuthenticationTicket.Identity;
        identity.AddClaim(claim: new Claim(type: "auth_token", value: 
           notification.ProtocolMessage.AccessToken));
        return Task.CompletedTask;
    }
}

While this solves my authorization issue, I want to make sure I am not opening up an attack vector by storing my auth_token in the identity claims. Can anyone tell me if this presents a security issue.

The reason I am concerned is that I was able to use Postman to create a simple request and manually pasted in the same Bearer authorization token into the request and then sending it. The response gave me the "secured" api data back. That says to me if anyone gets their hands on the auth_token they can access the API(or maybe Postman bypasses something?).

Tse

Answer 1

Storing the access token in a claim is permissible when using OWIN. It is comparable to the .NET Core recommended approach of storing them within AuthenticationProperties using RemoteAuthenticationOptions with SaveTokens. Both approaches result in the token being contained within the client's session cookie.

As a side note, you may consider taking advantage of IdentityServer4 ReferenceTokens if not already to reduce cookie size.

Mcmahan

I did go ahead and use Protect and Unprotect in system security just in case but that sounds fine. I will look into reference tokens. – Tse

@jwize, all above is correct. the only thing, probably missed in the answer is that the session cookie with SameSite and HttpOnly options is more secure than any other client side storage, so you should not concern unless you send the bearer to your client in plain state – Furtive