Identityserver4: Choosing the Access Token Type

Created on 24 Apr 2018  路  9Comments  路  Source: IdentityServer/IdentityServer4

Hi, I am actually confused about choosing the Access token Type for the client. From the documentation I it seems like usually the Access token comes in two flavors (1. JWT 2. Reference ), Identity Server defaults to "JWT" so can you provide in detail in which scenarios I need to choose the Reference token.

Though JWT is the default choice, I am curious to know under what scenarios I need to choose the Access Token?

question

Most helpful comment

Different apps have different security requirements based on context. I'd not make blanket statements about how people should do things without understanding all the requirements.

All 9 comments

Identity server 4 supports two types of AccessTokenType.JWT AccessTokenType.Reference Enums.cs for clients.

A JWT token would be a self-contained access token - it鈥檚 a protected data structure with claims and an expiration. Once an API has learned about the key material, it can validate self-contained tokens without needing to communicate with the issuer. This makes JWTs hard to revoke. They will stay valid until they expire.

When using reference tokens - IdentityServer will store the contents of the token in a data store and will only issue a unique identifier for this token back to the client. The API receiving this reference must then open a back-channel communication to IdentityServer to validate the token.

Above text shamelessly stolen from the documentation Reference Tokens

The basic difference being that the JWT token is validated itself. Where as the reference token must be validated on the identity server. Main thing i can see would be that you cant really expire an JWT its good as long as it hasn't expired. Where as the Reference token i stored on the identity server you could technically remove that causing it to be invalid from one minute to the next.

IMO just take JWT unless you really know what you are doing sometimes its best to just go with defaults.

Yay we have docs!

And people who read them even more shocking 馃く

To be clear, the intent is that the lifetime of access tokens will be very short, say 3 to 5 mins, for any site that is concerned about security. The only reason for a longer lifetime for the access token is to accommodate user experience troubles in completing some action before the token expires. The purpose for this limitation is to comply with (for example) the GDPR requirement that users are able to revoke permissions. That implies that any non-revocable token be short lived.

Different apps have different security requirements based on context. I'd not make blanket statements about how people should do things without understanding all the requirements.

All set on this issue -- can we close?

Hi Experts, I have a question which is related to tokens. I have asked same question and got some valuable answers

  • I am using identity token(JWT) for validating my APIs. but now i got requirement to make load balancing environment for my application in terms of token usage.

  • is it possible to store JWT in redis to make it sharable between multiple instances of identity server?

  • as i heard and received information from one of the chat we cannot store JWT tokens as they wont be having persistence. is it correct ?

  • one behavior i observed is without storing JWT token at anywhere, I have tested same token in load balancing environment which means same configuration or same issuer for both the identity instances. and it is working fine.

  • so by default JWT can be load balanced till it expires or we need to store explicitly? if required is it possible to store JWT into redis? if yes can u please suggest on this.

  • I have used below code some time back but i am able to store all other configuration data but not token.
    .AddOperationalStore(options =>
    {
    options.RedisConnectionString = Configuration["CacheConnectionString"];
    options.Db = 7;
    options.KeyPrefix = "IdentityToken";
    options.ConfigurationOptions = operationalStoreOptions;

                })
                .AddRedisCaching(options =>
                {
                    options.RedisConnectionString = Configuration["CacheConnectionString"];
                    options.Db = 5;
                    options.KeyPrefix = "IdentityRedis";
                    options.ConfigurationOptions = CachingStoreOptions;
    
                })
    

Please suggest on this as we are almost close to our release

Advance appreciation and thanks for your kind advice or suggestion on above query .......

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings