Page Comparison

...

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 Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODAT-65
	Access token expiration	Set in some cases but never checked	Jira Legacy server System Jira 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 Jira 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 Jira 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 Jira 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 Jira 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 Jira 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 Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODAT-67
	Silent refresh in stripes	Probably actually in stripes-connect	Jira Legacy server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key STCON-101
	Disable use of JWE by default for refresh tokens	See To Encrypt or Not to Encrypt?	Jira Legacy server System Jira 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 Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODAT-69

...

• 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

...

Several options were weighed:

•  Clients 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 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 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.