deviceauth: allow rotation of the RSA key used to sign the JWT tokens
Description
The service uses the RSA key to sign the JWT token and verify it.
The token contains information about the current device, and optionally about the tenant if running in a multi-tenant environment. The default token duration is one week. Once generated, the services store the token in a specific collection in the database.
The services expose a verification end-point (`/api/internal/v1/tenantadm/tenants/verify`), which extracts the JWT token from the HTTP Headers, verify the token signatures, and finally look up the token in the database.
Modify the service to accept two different RSA keys, an active one, used to sign the newly generated tokens, and a legacy one, used as a fallback to verify old JWT tokens. These changes allow proper rotation of the RSA keys using a transitionary period to let the old JWT tokens expire while new tokens are signed using the new RSA keys pair.
The service uses the RSA key to sign the JWT token and verify it.
The token contains information about the current device, and optionally about the tenant if running in a multi-tenant environment. The default token duration is one week. Once generated, the services store the token in a specific collection in the database.
The services expose a verification end-point (`/api/internal/v1/tenantadm/tenants/verify`), which extracts the JWT token from the HTTP Headers, verify the token signatures, and finally look up the token in the database.
Modify the service to accept two different RSA keys, an active one, used to sign the newly generated tokens, and a legacy one, used as a fallback to verify old JWT tokens. These changes allow proper rotation of the RSA keys using a transitionary period to let the old JWT tokens expire while new tokens are signed using the new RSA keys pair.
Ref: https://tracker.mender.io/browse/MC-618
Acceptance criteria:
The service accept an optional, legacy RSA key as fallback to verify old JWT tokens
Unit tests