Add a token based auth mode for authorising shape requests.

[thruflo]

Right now, the recommended pattern for read path auth for Electric is to run a web service in front of the Electric HTTP API, use it to authorise shape requests and then proxy the authorised rerequests/responses through; as per

This is flexible, uses common web service patterns (authorising access to an HTTP resource) and is fairly simple to implement. However:

• you have to run a separate auth proxy / endpoint for this purpose
• it conflates authorisation with proxying the data through
• the auth proxy needs to be aware of the shape request format
• the auth proxy becomes a bottleneck for data throughput
• the auth proxy either needs to be geo-distributed / run at the edge, or adds latency in front of the CDN

So, are there other strategies that we could add that would make sense and mitigate these concerns? Well, token based auth is a common pattern:

• application provides a public signing key, e.g.: using JWKS
• application can authorise requests by generating a signed token
• this token is provided to Electric / CDN
• Electric uses the public key and token contents to authorise the request

The benefits of this would be:

1. integrates with standard auth services
2. no need to run a proxy in front of Electric
3. no bottleneck
4. works with CDNs

Implementation

So, this feature request / discussion is to suggest adding token based auth to the Electric sync service, as an alternative auth mode. This could be enabled by env-var ELECTRIC_AUTH_MODE=token or some similar config schema. In single-tenant mode, the public key or JWKS url could also be configured by env var. In multi-tenant mode, we would need a schema for storing keys per tenant.

Electric could then implement a plug that would look for, validate and authorise tokens. This would require validating the contents of the JWT against the shape or URL being requested.

Usage pattern

This auth mode would work well with a flow where a client would connect to their API to get-or-create a shape. This request could return the shape ID and an auth token. The client could then use to connect to the sync service directly to consume the shape.

/PUT {params} https://my-api.example.com/get-or-create-shape
=> {shapeId, authToken}

/GET https://electric-sync-service.example.com/:shapeId, headers: [auth: authToken]

If the shape consuming request is rejected (shape ID disappears on the server or the auth token expires) the client would reconnect to the API to get a new ID an/or token as necessary.

[thruflo]

This is now implemented in #1963