As described in step 7 of the login flow, upon querying the /token endpoint of the microservice with a valid authorization code retrieved from previous steps, a signed JWT with the following serialized properties should be returned:
email: the waterloo email corresponding to the userid: a unique id representing the user (this could just be the UUID assigned to the user entity)
Note that based on the parameters to the /token endpoint (described here), this should happen only if the following conditions are true:
- The provided auth code exists and is valid (i.e points to the correct
clientId)
- The
EncryptedClientSecret corresponding to the clientId matches the provided client_secret.
This endpoint should appropriately sanitize query/body parameters (refer to how other use-cases achieve this through parsing middleware) and be sufficiently unit tested.
As described in step 7 of the login flow, upon querying the /token endpoint of the microservice with a valid authorization code retrieved from previous steps, a signed JWT with the following serialized properties should be returned:
email: the waterloo email corresponding to the userid: a unique id representing the user (this could just be theUUIDassigned to the user entity)Note that based on the parameters to the
/tokenendpoint (described here), this should happen only if the following conditions are true:clientId)EncryptedClientSecretcorresponding to theclientIdmatches the providedclient_secret.This endpoint should appropriately sanitize query/body parameters (refer to how other use-cases achieve this through parsing middleware) and be sufficiently unit tested.