...
See the epic for a list of all the affected modules and associated stories for the work to upgrade to RTR.
This page is to serve as a guide for implementing RTR in modules and scripts and 3rd party integrations. It also provides configuration options for sys ops.
How RTR works
In RTR, the user provides a set of credentials (such as a username and password) and then receives two tokens back: a refresh token (RT) and an access token (AT). Both the RT and AT have a time to live (TTL) specified in the JWT claims (the properties of the JWT) as the exp claim. The user can provide the AT in subsequent requests to authorize access to a given resource so long as the AT hasn't expired. The user can provide the RT to get another AT when the current AT expires, which provides a new RT and AT set. This is the "refresh" part of RTR.
...
| Info |
|---|
The default expiration of an AT is 10 minutes. If client code needs to use this token after this 10 minute period is up, client code should request a new AT by logging in agin. Note that once the AT reaches the FOLIO system the AT is converted into a non-expiring token. So a long-running operation that takes more than 10 minutes won't be subject to the expiration of the original AT. |
...
Configuration guide for sys ops
Systems operators have the ability to configure the the TTLs on the AT and the RT. For configuration instructions please see mod-authtoken's readme here. Configuration can override the default expiration for the AT, the RT or both. Configuration can apply globally to the cluster or per tenant.