Implement JWT aud claim as a security requirement

[fisher60]

Summary

Currently all tokens are created identically, regardless of which service was intended to consume them. Any token created for a service can be used to authenticate on any other service. This is a large security vulnerability since we want this project to be publicly usable for any third-party services.

Right now, if Service A creates a login request with abandon auth, the token for Service A is valid for 60 seconds on any other service that uses abandon auth. So Service A can use the login token it was given to authenticate with Service B. This is undesirable since Service A might be a website owned by a random individual, and Service B could be a production application owned by abandon tech or any other individual. It is not desirable that logging in with Service A would result in Service A fully owning your account for Service B. Therefore we need a way for each service to confirm that the token they were given is meant to authorize them with that respective service.

The easiest (and most standard way) to solve this is by using the aud claim of the JWT.

We will require that all applications that wish to use abandon auth are given a client ID and client secret (a strong password/api token). When an application requests a login, it will also send its client ID and client secret to Abandon Auth. If the request succeeds (the client id and secret are authenticated/authorized) Abandon Auth will issue the login token with an aud that contains the client ID.

Acceptance Criteria

Abandon Auth JWTs include the aud claim, the aud claim is the authenticated client ID of the client which invoked the request.

[fisher60]

Below is an example of a malicious auth flow. This flow would result in a complete account takeover for anything using Abandon Auth. This attack would not be visible to the user as they would not be aware that they are logging in with abandon auth. User would believe they are just authenticating with Discord.

[fisher60]

https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow#how-it-works

[fisher60]

We will represent the aud claim as a list of strings that will be developer application UUIDs

[fisher60]

Update after much discussion:

We will again be changing the auth flow quite a bit to be the above. This will be discussed further in a TBD issue.

1. Client initiates a login request to AbandonAuth and includes application ID and redirect UI to the backend. AbandonAuth verifies this is a valid app id and callback URI combo
   2 + 3. login with discord, basic stuff, redirect to AbandonAuth
2. Using the verified redirect URI from 1, forward the login request with an exchange token with identity permissions for AbandonAuth and possibly an aud of the application ID (redundant, but maybe more secure)
3. Use the exchange token to authenticate a user/identify user on abandon auth and using the backend's own access token. AbandonAuth confirms the exchange token is valid and the aud claim matches the authenticated developer application that sent the request
4. AbandonAuth sends a long-lived identify token for the user. This token does not have permission to login on AbandonAuth as the user, but just has identify permissions.
5. The user is now authenticated and the application can do whatever it deems fit with the user's session. Most likely the application will redirect the user to the correct, known frontend application as defined by the backend and either issue a new token, or allow the frontend to store the AbandonAuth token to keep the user authenticated.