Spring Boot JSON API to control verification of access and refresh tokens of prisoners for HMPPS.
./gradlew build
./gradlew bootRun
/health/ping
: will respond with{"status":"UP"}
to all requests. This should be used by dependent systems to check connectivity to token-verification-api, rather than calling the/health
endpoint./health
: provides information about the application health and its dependencies. This should only be used by token-verification-api health monitoring (e.g. pager duty) and not other systems who wish to find out the state of token-verification-api./info
: provides information about the version of deployed application.
Token verification api is best tested by interaction with auth (https://sign-in-preprod.hmpps.service.justice.gov.uk/auth/). To manually smoke test / regression test token verification api prior to release:
- Login to auth
- Navigate to whereabouts
- In separate tab navigate directly to auth and logout
- In previous tab perform action - should be directed back to auth as not logged in (only if enabled)
All the above events will generate calls to token verification and will fail if token verification is not working correctly. The last item will only succeed if token verification is enabled for that application in that environment.
We are using Redis repositories from Spring Boot to store the tokens in Redis.
Each token record consists of a jwtId
, authJwtId
and subject
. The jwtId
is the jti
in an individual access
or refresh token granted to a client. The authJwtId
is the owning session in auth from which the access token or
refresh token was granted, or the jwtId
for client credentials if there is no owning session. The subject
is the
username, or where that isn't set (e.g. for client credentials), the client id of the grant. Both the authJwtId
and
subject
are indexed in Redis, which means that there are Redis sets for each stored separately too.
If we insert a token record for:
jwtId: a5b0dd32-2763-4577-bce8-7339c8bd4bd2
authJwtId: c70857f7-314e-4e21-a52f-34f995d465ff
subject: ITAG_USER
into Redis we will therefore get:
- a Redis hash at
token:a5b0dd32-2763-4577-bce8-7339c8bd4bd2
with contents:1) "_class" 2) "uk.gov.justice.digital.hmpps.tokenverification.data.Token" 3) "jwtId" 4) "a5b0dd32-2763-4577-bce8-7339c8bd4bd2" 5) "authJwtId" 6) "c70857f7-314e-4e21-a52f-34f995d465ff" 7) "subject" 8) "ITAG_USER"
- An index Redis set at
token:a5b0dd32-2763-4577-bce8-7339c8bd4bd2:idx
linking the token to the auth JWT and subject, with members:1) "token:authJwtId:c70857f7-314e-4e21-a52f-34f995d465ff" 2) "token:subject:ITAG_USER"
- A phantom Redis hash record at
token:a5b0dd32-2763-4577-bce8-7339c8bd4bd2:phantom
with same contents as the Redis hash at 1, but with a 5 minute later expiry. This is so that Spring can clean up the records on expiry. - An index Redis set for all tokens granted from the auth owning session at
token:authJwtId:c70857f7-314e-4e21-a52f-34f995d465ff
with initial members:1) "a5b0dd32-2763-4577-bce8-7339c8bd4bd2"
- An index Redis set for all tokens granted for the subject at
token:subject:ITAG_USER
with initial members:1) "a5b0dd32-2763-4577-bce8-7339c8bd4bd2"
Tokens are stored in a redis instance in AWS. Follow DPS Runbook to connect to the redis store in a cloud platform environment.