Code exchange vs local id_token verification

Successful registration and authentication calls return a code and id_token.

Similar to OpenID Connect, the code can be exchanged for an ExtendedPrincipal by calling the Passlock REST API, whereas the id_token can be verified locally to obtain a principal, thereby avoiding the need for an additional network call.

You might be tempted to favour the id_token, and in many cases this will be more performant, however there are a few things to be aware of…

JWT verification

The id_token is a JWT, so if you’re not using the Passlock server library you’ll need to use another JWT library, capable of handling public key verification along with JSON Web Key Sets (JWKS). In contrast, the code can be exchanged for a Principal using a simple REST call.

Initial network call

Passlock signs the id_token using a private key. The corresponding public key is exposed in a JSON Web Key Set (JWKS). To verify the id_token is authentic, the Passlock server library (or your own JWT library) needs to first fetch the public key from our JWKS endpoint.

The public key will be cached, however the first call will still need to hit the JWKS endpoint. If you’re running in a serverless environment e.g. AWS Lambda or Google Cloud Functions and cold starts are likely, JWT verification is likely to be slower than code exchange.

Principal vs Extended Principal

To keep the encoded JWT down to a reasonable size, we only include core data. In contrast, code exchange returns an ExtendedPrincipal which includes more data.