Revision history [back]

click to hide/show revision 1
initial version

Keystone v3 Token Validation

Hello,

Planning on using keystone for an application as the identity service.

I know in v2.0 a token can be authenticated and therefore validated and decoded.

I know in v3.0 there's an API method (GET /auth/tokens/) that can be called to verify a token.

My only concern with the v3.0 API is that during an authentication check, the act of querying keystone to verify is added delay and would essentially hamper API performance. Granted I could cache the tokens, but would I still need to pull 'revoked' tokens?

I noticed that a v3.0 token uses the same signing system as v2.0

Is there any harm, short and long, in using the v2.0 system of token validation/decoding on a v3.0 Token?

Keystone v3 Token Validation

Hello,

Planning on using keystone for an application as the identity service.

I know in v2.0 a token can be authenticated and therefore validated and decoded.

I know in v3.0 there's an API method (GET /auth/tokens/) that can be called to verify a token.

My only concern with the v3.0 API is that during an authentication check, the act of querying keystone to verify is added delay and would essentially hamper API performance. Granted I could cache the tokens, but would I still need to pull 'revoked' tokens?

I noticed that a v3.0 token uses the same signing system as v2.0

Is there any harm, short and long, in using the v2.0 system of token validation/decoding on a v3.0 Token?Token? In other words, pull the certificate from keystone (every minute or two for example) and check the signature of the token? Using the certificate is more heavy on system resource, but at least it would avoid marshall/unmarshall/network latency for verify token via the API for each single request