Code exchange vs id_token verification

Successful registration and authentication calls return a code and id_token. Similar to OpenID Connect, the code can be exchanged for a Principal by calling the Passlock REST API, whereas the id_token can be verified locally, 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.

Network calls can’t be avoided

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 needs to first fetch the public key from the JWKS.

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 that code exchange.

Its computationally expensive

Probably not a big concern, but JWT verification is computationally expensive, as it involves public key verification. In contrast, code exchange is a simple (non-blocking) network call.