R03 Do not transfer JWT token as a URL parameter on login

[rikukissa]

Description

• This feels like we should implement a more OAuth2 style mechanism to the login - client exchange. This could help us build other UIs also later on
• Login supplies client with a temporary token that can only be used once to fetch the real JWT
• Research: what would doing real OAuth2 cost us?

Security assessment details

Technical Overview

The application included the JSON Web Token (JWT) in the URL. Sensitive information within URLs may be logged in various locations, including the user's browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing such information into the URL increases the risk that an attacker will capture them.

Potential Impact if Exploited

A successful attack could allow an attacker to gain access to the environment as an authorised user.

Recommendations

The application should only transmit sensitive information following a successful POST request, and avoid including it in places that may be stored by the browser for extended periods, or places that may be visible to people other than the user.

Acceptance criteria

GIVEN WHEN THEN

Design

(Link to Figma)

Dev tasks

• [ ] Auth's /verifyCode needs to be changed to return an auth_code, this can be a random UUID for example. It needs to be saved into Redis and it needs to expire after 5 minutes
• [ ] Pass the auth_code to the client application via a query param and redirect the user
• [ ] The client application then needs to read this query param and do one more POST call to auth's /token (through gateway's /auth/token) with

  {
  "grant_type": "authorization_code",
  "auth_code": "one-time-auth-code"
  }

• [ ] Amend this route handler to handle this new grant_type. It reads the auth_code from Redis, matches it, and removes it. This endpoint returns the token and then the client application can use it similarly as previously.
• [ ] Add a comment that the "grant_type": "authorization_code" doesn't fully implement OAuth 2 yet, as it would also need client_id and client_secret.
• [ ] Rename the directory from packages/auth/src/features/system to token or something more descriptive.

[rikukissa]

Just a note for myself – full OAuth2 implementation is probably where we are headed in the long term given that:

• We need other clients to use the same login mechanism
• We need another layer of complexity for how token is transferred to the client
• There are exploits in how we currently do this

https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce