Specific Errors

[iMacTia]

Hello,

just wondering if could be a good idea to introduce more specific errors for token validation.
My problem is that, when refreshing a token using the token endpoint, sometimes I get an "Invalid Grant" error, but I can't understand if this is due to a wrong or expired refreshToken.
I know it seems a useless difference, but in my case I have an application that doesn't store the plaintext token (for security reasons). For this reason, I'm not able to distinct this two cases.

Am I missing something? Can I read the refreshToken Expiration from outside IdSrv.v3 like for Access Tokens?
Alternatively, having more specific errors would help to manage this correctly.

Thanks in advance,

Mattia

[brockallen]

The spec is very clear about what errors should be issued for which scenarios.

[iMacTia]

Are you referring to the OAuth2 or OpenID spec?
If the errors can't be modified, what is the best solution if I don't want to save plaintext tokens in my application? Why the refreshToken expiration is not included in the TokenResponse like the Access Token's one?

[brockallen]

Well, both.

I don't follow the comment about saving plaintext tokens.

If the RT returns a failure, then you should probably assume the RT is invalid. Perhaps the user revoked it, perhaps it expired, etc. At this point your client will have to start over.

[iMacTia]

Ok, try to imagine a scenario in which the RT is stored after being symmetrically encrypted with the user password (actually something shorter, like a PIN), which is not stored as well by the application. In order to access the application functions, the user must provide this PIN. If and only if the PIN is correct, we correctly decrypt the RT to obtain a new AT. If the server respond with a generic "Invalid Grant", I'm not able to understand if the PIN is wrong or the token has been revoked/expired.

All of this has been done in order to avoid storing security data in the application (at least in plaintext).
Any clue/advice on how to solve this situation with IdSrv tools?

[brockallen]

Put a verification/checksum/header/magic number of some sort in the protected value to validate once unprotected?

Also, the RT should be of no value without the client secret, so the RT by itself isn't completely vulnerable.