JWT authentication for rest-api

[rkrenn]

JWT authentication introduces a dedicated "/tools/login" endpoint to authenticate a user with credentials provided via http "basic authentication" header. it will return a secure token ("JWT") string, that can be passed to subsequent rest-api requests via the "bearer authentication" header. The token authenticity is verifyied using the groupkey of the user's department, so no new keys had to be introduced (generated).

since the phoenix database stores subject PII data encrypted with PBE (password-based encryption) with the department group key, every service method requires to provide the user credentials (to encrypt/decrypt the group key and then the subject PII). for JWT authentication this means veryfying a JWT validity is not enough, the JWT token also has to carry the credentials in order to run servicemethods.

This is achieved by including the RSA-encrypted password to the JWT token payload. In phoenix every user already owns an internal RSA keypair (for signing eCRFs), which is re-used here. The private key is used to encrypt the password, while the public key is used to decrpyt. The security holds as long an attacker does not hold both public key and a captured JWT in his hands, therefore http ("bearer") header containing the JWT string should not be recorded in the http server logs.

it's up to the rest-api consumer ther to include a "validity_secs" query parameter when creating the JWT. Eg. "/tools/login?validity_secs=300" will render a token that is accepted up to 5 minutues only, until it has to be renewed.

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
4 Vulnerabilities
0 Security Hotspots
10 Code Smells

0.0% Coverage
0.0% Duplication