Validation Mode - Stopping idsvr error being raised

[parkinsona]

Hi,

I wasn't sure if this should be posted in the idsvr repo or this one, so I hope its in the right place.

I have the following error coming out of identity server :

 ERROR IdentityServer3.Core.Validation.TokenValidator - JWT token validation error

System.IdentityModel.Tokens.SecurityTokenExpiredException: IDX10223: Lifetime validation failed. The token is expired.

This is the code I have for securing my API:

   app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions
            {
                Authority = Properties.Settings.Default.AuthBaseAddress,
                ValidationMode = ValidationMode.ValidationEndpoint,                   
                RequiredScopes = new[] { "profile_api", "mysite_api" }
            });

I understand that this will hit the idsvr token validation endpoint to ensure the token being passed into my API is valid for the authority. Identity server recognises that token as invalid because it has expired, but this is raised as an exception. Should it be raised as a warning?

Also, I'm not quite sure what is supposed to happen if I change the validation mode to Local. From what I can tell from the doco Local doesn't hit the Validation endpoint? I might be wrong.

Is there a way to log these token validation errors as warnings in identity server and instead raise them as exceptions in the API that uses them? My reasoning is that if one external party keeps using old tokens, I don't want to get errors from idsvr that are just from expired tokens.

[parkinsona]

If its not possible to turn the error off, is there some way to get the information from the token put into the exception message? The above doesn't tell me anything else about where the token might have come from.

[leastprivilege]

Are you talking about logging on identityserver or in the validation middleware?

[parkinsona]

To clarify, the error message I gave above is coming from Identity Server.

In the API that uses the accessToken, I would like to be able to capture the reason for the token failure. Eg. Expired or bad format, etc. So that a caller of the API has more info to run with. At the moment all they get is "Authorization has been denied for this request"

I think I would need to add this to the validation middleware used by my API, however I'm not sure how to go about that.

[leastprivilege]

There are two valid error responses: 401 (token not good - or not existent) and 403 (token good - but caller not authorized).

That's all the client cares about.

[parkinsona]

On the client end, they receive a 401 for an expired token and a 401 for a completely invalid token (eg. "XXXXXX"). How can they know from that if the cause is an old token? Now I'm hoping our client will check the lifetime of their tokens so that they get a fresh one if its about to expire, but that is outside my control.

Is Local Validation still supposed to hit the Validation Endpoint?

[leastprivilege]

Even if they would know the exact reason why token validation failed - 401 means: "get a new token".

local validation is local.

[parkinsona]

Local to the API or Local to IdentityServer?

[leastprivilege]

API

[parkinsona]

Ok that's what I thought. If that's the case, is there a reason it was trying to validate against Idenitty Server when I sent validationMode to local?

[leastprivilege]

no

[parkinsona]

Not sure what was happening the other day, but Local ValidationMode is working as expected now. I was sure I'd rebuilt the API properly, but I mustn't have.

Is there any disadvantage to using Local?

[senseicz]

@parkinsona - here is how I understand ValidationMode works:

• Local – in this mode, API will only connect once to Identity Server during its startup time and will download public portion of Identity Server’s certificate. This is then used to validate signature on incoming JTW tokens.
• ValidationEndpoint – in this mode API will contact Identity Server with every request coming to API, validating token on Identity Server side. This is being used when Reference tokens are being used (Access Token itself will always stay on Identity Server while client will get only a Reference Token – this is just an identifier with no data inside. Reference Token is used the very same was as standard Access Token – via Authorization: Bearer request header. When such token arrives to API, it will close the loop by calling Identity Server endpoint, validating that such Reference Token is still valid.)
• Both – in this mode, Local mode will be used for real JWT tokens while ValidationEndpoint mode will be used for Reference Tokens. JWT tokens have . (dot) while Reference Tokens does not - that is how they distinguish between what type of validation will happen.

[parkinsona]

Thanks very much for that clarification. I'm thinking "Both" gives the best of both worlds, and if you have to go back to idsvr it will work that out for you.

@leastprivilege , is there any benefit in having a config option to log failed token validations as a warnings instead of errors.

[leastprivilege]

Open an issue for that in identityserver please.