Team API Keys & Access Token management with hashing

[dobrac]

Changes

• Database migration for api keys and access tokens hashing
• New endpoints for Teams API Key and Access Tokens management
• Adds Team API Keys and Access Tokens hashing

Hashing
Hashing of Team API Keys and Access Tokens is done using sha256. It should be okay, as we have already 160bits secure API Keys/Token generation + API Keys are "confidential data at rest". Hash is only generated from the key part, key/access_token prefix is excluded. It uses bytes array directly.

Hashes are stored in the format:
"$sha256$%hash"

DB Changes
Access Tokens

ADD COLUMN id uuid DEFAULT gen_random_uuid(), // Used for token deletion
ADD COLUMN access_token_hash text UNIQUE, // New hashed value
ADD COLUMN access_token_mask text, // Masked value used for showing to the user (if required)
ADD COLUMN name text NOT NULL DEFAULT 'Unnamed Access Token'; // Naming for us to reference sources of creation + if exposed to the user, the naming might help the user

Team API Keys

ADD COLUMN api_key_hash text UNIQUE, // New hashed value
ADD COLUMN api_key_mask character varying(44); // Masked value used for showing in the dashboard 

Endpoints
Why to move API Key managent to the Infra API

• There is a need of hashing API Keys on the /teams endpoint in the API - because of it's usage in CLI (so the hashing and key creation would have to be duplicit if part of dashboard)
• For custom clusters, it will be easier to handle Team API Keys management on their cluster (connected to their Supabase instance) as opposed to if/switch of Supabase on the dashboard side

// Required headers: X-Supabase-Token
POST /access-tokens - create new access token
DELETE /access-tokens/{access_token_id} - delete existing access token

// Required headers: X-Supabase-Token, X-Supabase-Team
GET /api-keys - list of all team api keys
POST /api-keys - create new team api key
PATCH /api-keys/{api_key_id} - update team api key name
DELETE /api-keys/{api_key_id} - remove team api key

[linear]

E2B-1558 Start creating hashes alongside API keys/access tokens in DB when creating new ones

[0div]

LGTM, although—not to be that guy—but needs tests.

[0div]

• is it always "the last four" ? in which case maybe being more explicit about that expected count in the naming of hardcoded values.
• boring but good idea to apply defensive programming for critical areas like this, e.g. validate the length of value (even if expected to be sha sum) beforehand to avoid a negative value after subtraction.

[dobrac]

is it always "the last four" ?

Right now that's how we've defined the masked API key to look like. It doesn't have any real effect on the keys though, this is just for the user. What would be your proposal for the renaming?

boring but good idea to apply defensive programming

Okay, I will add it

[0div]

ohh, i see where my confusion stemmed from. The term "mask" for me has another meaning in the byte manipulation/crypto world. To be clearer i would probably renamed this as "hiding"

[dobrac]

do you mean HideKey? I was just following the naming convention we've already had there

[0div]

yeah HideKey is clearer IMO

[dobrac]

I would keep the MaskKey as I think the mask is actually used to do exactly this action (based on what I've found)

[dobrac]

LGTM, although—not to be that guy—but needs tests.

Added unit and integration tests

[jakubno]

I am missing logs, at least for error and info in the end of an successful interaction as deleting an api key

[dobrac]

I am missing logs, at least for error and info in the end of an successful interaction as deleting an api key

all http endpoints are logged with their results, if it is an internal error, we log also the reason (sendAPIStoreError)