Suggestion: Sets expiration for OAuth access tokens

[MacTwister]

Is your feature request related to a problem? Please describe.

No issue, just an observation. Configured with commit 8 years ago, which I am guessing was so access tokens could be used like "personal access tokens" with backed applications/scripts, which do not have a user auth flow.

So just wanted to make a note and ask the question, keeping in mind when most apps/tokens are used only for authentication (to then receive the user's info).

Related Doorkeeper gem config:

fablabs.io/config/initializers/doorkeeper.rb

Lines 31 to 33 in 752b938

	# Access token expiration time (default 2 hours).
	# If you want to disable expiration, set this to nil.
	access_token_expires_in nil#2.hours

Doorkeeper docs: https://github.com/doorkeeper-gem/doorkeeper/wiki/Customizing-Token-Expiration#access-token

Describe alternatives you've considered

Alternative solutions would need to be thought up so that scenarios where scripts/servers need can continue to work with the API to (ie. create users for Fab Academy, make reports on labs, etc).

• Have a custom button on the OAuth application page
  • that just manually, creates an access token with no expiry date
  • (inc. tmp show token once, table list existing, revoke token, etc)
  • Probably the easiest (more or less one line to create a token in doorkeeper controller)
• Enable Doorkeepers' "refresh access token" mode
  • then scripts need/can be updated to use that token to fetch a new access_token every time one needs to work with API. (part of OAuth spec).
  • Not sure on side effects vs no expiry date. More work for the 3rd-party scripts
• Create a new personal access token setup
  • simple model/table,
  • adding an auth check method to the API controller (on top of doorkeeper).
• Maybe Rails has a default setup (or gem) backed-in to do this.

Additional context
Need to process and report on the current NGINX logs of the API/APP to see if any existing API calls are relaying on this setting (outside Fab Academy). For example, I quickly noticed, that there were calls to the /api/2/labs endpoint by a client. So, we can look into the impact.

Only security related issue I currently see is if access tokens would leak/stolen (from 3rd parties). Though tokens are assigned to a user, if an admin token would leak. The API access is depended on the token's users' existing access rights.