RTR: x-okapi-token, step 2; Update TokenHeader to utilize the Access Token. #3
Description
This issue is generated from spike #2 .
Follow up regarding the Access Token after it is received by something like mod-workflow.
Okapi creates a new token before it calls a module's API. This is needed to add modulePermissions, for example for https://github.com/folio-org/mod-users-bl/blob/v7.10.0/descriptors/ModuleDescriptor-template.json#L13-L19
The Access Token received at this point should therefore be the non-expiring token.
It should be safe to use the received token without needing to alter mod-workflow or any of the processes.
The TokenHeader needs to be updated to handle the HTTP Cookie.
Given that the Cookie has an expiration, we should instead use the X-Okapi-Token.
The token expiration is also not needed.
The Refresh Token is also not needed.
The TokenHeaderResolver is what needs to be updated to perform the additional logic of reading and parsing the HTTP(s) Cookie.
The TokenResolverWebMvcConfig might also need updating.
Be advised that the RTR Configuration guide for sys ops documents a LEGACY_TOKEN_TENANTS environment variable.
For system operators who wish to take full advantage of the new more secure tokens, there is is a new system property and environment variable called LEGACY_TOKEN_TENANTS . When not set (the default), in Poppy, Quesnelia, Ramsons, and Sunflower, all tenants are legacy token tenants. When set to a list of tenant ids, only those tenants will be considered legacy token tenants. When set to an empty string, no tenants are legacy tenants. A legacy tenant is defined as a tenant for which the legacy endpoint authn/login will not return a 404.