Authentication method for internal services

[fisher60]

Summary

We need to securely create and authenticate accounts for internal services. It is not practical to use an external auth provider for these accounts. We should determine how we would like to implement this.

The most secure method would be to generate accounts that can authenticate via a secure refresh token. We can either manually create special service accounts (only to be used internally) or we can offer this account type as a service (a developer account, not to be regular-user-facing).

We would generate a secure, long-lived refresh token that can be negotiated for a short lived JWT access token, this JWT access token can then be negotiated with the invoking login service for whatever form of auth that services wishes to use.

Another option is to do the above process, but replace the refresh token with username/password authentication. Although this will likely not be as secure.

Proposed Acceptance Criteria

• A registration method exists to create a developer/internal service account
• Internal service accounts are given a secure, generated password/token that is only available as plain text during registration
• Created tokens are securely hashed and salted and stored on the database so that we can authenticate the account again later
• An internal service account can authenticate/identify using a login endpoint on this server, this endpoint is primarily meant to be called by other sites/services (much like existing discord auth) in order to negotiate a longer-lived token
• The registration method is either public or private, depending on how we wish to implement registration

[fisher60]

We should create endpoints for these specific actions (like creating/deleting service accounts)

I am thinking of a logical organization of developer accounts that are linked to a single user account. These should all depend on user JWT. This will allow secure and easy management of developer and service accounts via a single user account.

Developer account

user_uuid: uuid
refresh_token: hashed_and_salted_refresh_token

# Given a user JWT as auth dependency, returns a list of developer account UUIDs for accounts belonging to the current user
GET /developer_accounts 

# Given a user JWT as auth dependency, create a new developer account and return the refresh token as plain text
# The refresh token will never exist as plain text on abandon auth after this single request
POST /developer_accounts

# Given a developer_account JWT as auth dependency, return the developer account uuid (as authentication)
GET /developer_accounts/me 

# Reset the secret for the given account, uses User JWT to authorize
GET /developer_accounts/<account_uuid>/reset_secret

# Given a devloper_account refresh token and UUID, return a short-lived access token 
# Short lived JWT for a developer account, not a regular user JWT as developer accounts should not be able to own/create developer accounts, 
# However we should be able to authenticate the developer account with the `/me` endpoint for compatibility with other APIs.
POST /developer_accounts/login  

# Using the user JWT, delete a developer account (if the user is the owner of the developer account)
DELETE /developer_accounts/<account_uuid>  

[fisher60]

I will be naming this feature developer applications

[fisher60]

In order to support this feature, we will be adding encrypted passwords as refresh tokens for internal applications.

We will also need to authenticate AbandonAuth users on AbandonAuth in order to create and manage their developer applications. Due to this we will need to distinguish between short-lived tokens for token exchange during OAuth and long-lived tokens for persistent user sessions on AbandonAuth.

I will be adding a new endpoint for logging into AbandonAuth. This will differ than the existing endpoints as this will use AbandonAuth's 3rd-party OAuth providers to authenticate users on AbandonAuth itself.

This will also pave the way for an AbandonAuth UI and account management options.