...

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:

• Jira Legacy
  server System JiraJIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key FOLIO-2556

  – FOLIO Authentication Token Architecture Improvements 

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":

...

• Look at existing OSS - https://spring.io/projects/spring-security, https://www.keycloak.org/

Decisions

Appendix

Which APIs should clients use to refresh access tokens?

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.

...