...
| Status | Functionality | Notes | Story |
|---|
  | Ability to get a valid refreshToken | POST /refreshtoken - requires "secret" permission not mentioned in the module descriptor | Already done |
| Ability to get a new access token via valid refresh token | POST /refresh | Already done |
  | Ability to revoke a refresh token | See Ability to Explicitly Revoke a RefreshToken | Not needed |
| Ability to revoke ALL refresh tokens | May not be urgent - if needed restart the auth module(s) with a new signing key. See Ability to Explicitly Revoke a RefreshToken | Not needed |
| Configurable access and refresh token expiration | Both are hardcoded - 10min/24hrs | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-65 |
|---|
|
|
  | Access token expiration | Set in some cases but never checked | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-64 |
|---|
|
|
| Refresh token expiration | Refresh tokens that are expired are considered invalid | Already done |
| Validation that a refresh token was generated by this FOLIO Instance | Right now depends on signing key. If we go with rotating refresh tokens (and keys) this is no longer an issue. | Not needed |
| mod-login-saml supports refresh tokens | Currently only returns an access token | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODLOGSAML-57 |
|---|
|
|
| Gracefully handle access token expiration in module-to-module requests | See Gracefully Handle Access Token Expiration in Module-to-Module Requests | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-66 |
|---|
|
|
| Ensure we're not caching access tokens in edge-sip2 | Can probably be wrapped into the existing story for handing token expiration/invalidation | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | SIP2-71 |
|---|
|
|
| Silent refresh in edge-common | Currently caches access tokens for a configurable amount of time | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | EDGCOMMON-22 |
|---|
|
|
| Refresh token rotation upon use | See Refresh Token Rotation and Automatic Revocation Upon Multiple Uses | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-67 |
|---|
|
|
| Automatic revocation of refresh tokens when used more than once | See Refresh Token Rotation and Automatic Revocation Upon Multiple Uses | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-67 |
|---|
|
|
 | Silent refresh in stripes | Probably actually in stripes-connect | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | STCON-101 |
|---|
|
|
| Disable use of JWE by default for refresh tokens | Signing, but no encryption. See To Encrypt or Not to Encrypt? | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-68 |
|---|
|
|
| Refactor/Combine access/token endpoints | See Combine /token and /refresh endpoints in mod-authtoken? | | Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | MODAT-69 |
|---|
|
|
...
Spike:
Related:
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | FOLIO-1233 |
|---|
|
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | FOLIO-2524 |
|---|
|
| Jira Legacy |
|---|
| server | System JiraJIRA |
|---|
| serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | UIU-1324 |
|---|
|
...
- Always check access token expiry during authorization -
What about token cache? - Access tokens without a valid expiration will be rejected
- Access tokens generated for module-to-module purposes have a new expiration, i.e. they don't inherit the expiration from the incoming token
...
In order to avoid proliferation of modules dependent upon the authtoken interface, we should create an endpoint in mod-login which clients can use to refresh their access token. Other options that we considered are documented in the Appendix.
Since stripes/stripes-connect will likely store refresh tokens in a httpOnly cookie, this new refresh endpoint will accommodate two mechanisms for communicating refresh tokens, or "tokenTransport":
...
Several options were weighed:
- Clients call mod-authtoken's refresh endpoint directly (e.g. POST /refresh)
- Pros:
- No changes are needed to mod-login
- Cons
- Proliferation of dependencies on mod-authtoken. Edge APIs, Stripes, etc. will now need to call mod-authtoken directly, something not previously needed.
- Clients provide a refresh token when calling mod-login's login endpoint (e.g. POST /authn/login)
- Pros:
- No new endpoints required
- Clients always call the login endpoint, either with credentials or a refresh token
- Cons
- Overloading the login endpoint is confusing and messy - breaking changes
- Clients provide a refresh token when calling a new refresh endpoint in the login module (e.g. POST /authn/refresh)
- Pros:
- Distinct endpoints for login and refresh is cleaner - and makes it clear what the purpose of each is
- The existing login endpoint doesn't necessarily need to change, though it might be changing anyway for FOLIO-2523
- Cons:
- Clients need to know which endpoint to call, depending on whether they're furnishing credentials or a refresh token.
...