Skip to main content
For a quick way to get started before implementing custom auth, Development Tokens can be used instead.
The process is as follows:
  1. The client authenticates the user using the app’s authentication provider and typically gets a session token — either a third-party authentication provider or a custom one.
  2. The client makes a backend call (authenticated using the above session token), which generates and signs a JWT for PowerSync.
    1. For example implementations of this backend endpoint, see Custom Backend Examples
  3. The client connects to the PowerSync Service using the above JWT.
  4. PowerSync verifies the JWT.
The requirements are: A key pair (private + public key) is required to sign and verify JWTs. The private key is used to sign the JWT, and the public key is advertised on a public JWKS URL. Requirements for the key in the JWKS URL:
  1. The URL must be a public URL in the JWKS format.
    1. We have an example endpoint available here; ensure that your response looks similar.
  2. Supported signature schemes: RSA, EdDSA and ECDSA.
  3. Key type (kty): RSA, OKP (EdDSA) or EC (ECDSA).
  4. Algorithm (alg):
    1. RS256, RS384 or RS512 for RSA
    2. EdDSA for EdDSA
    3. ES256, ES384 or ES512 for ECDSA
  5. Curve (crv) - only relevant for EdDSA and ECDSA:
    1. Ed25519 or Ed448 for EdDSA
    2. P-256, P-384 or P-512 for ECDSA
  6. A kid must be specified and must match the kid in the JWT.
Requirements for the signed JWT:
  1. The JWT must be signed using a key in the JWKS URL.
  2. JWT must have a kid matching the key in the JWKS URL.
  3. The aud of the JWT must match the PowerSync instance URL.
    1. To get the instance URL of a PowerSync instance when using PowerSync Cloud: In the project tree on the PowerSync dashboard, click on the “Copy instance URL” icon.
    2. Alternatively, specify a custom audience in the instance settings.
  4. The JWT must expire in 60 minutes or less. Specifically, both iat and exp fields must be present, with a difference of 3600 or less between them.
  5. The user ID must be used as the sub of the JWT.
  6. Additional fields can be added which can be referenced in Sync Rules parameter queries.
Refer to this example for creating and verifying JWTs for PowerSync authentication. Since there is no way to revoke a JWT once issued without rotating the key, we recommend using short expiration periods (e.g. 5 minutes). JWTs older than 60 minutes are not accepted by PowerSync.

​
Rotating Keys

If a private key is compromised, rotate the key on the JWKS endpoint. PowerSync refreshes the keys from the endpoint every couple of minutes, after which old tokens will not be accepted anymore. There is a possibility of false authentication errors until PowerSync refreshes the keys. These errors are typically retried by the client and will have little impact. However, to periodically rotate keys without any authentication failures, follow this process:
  1. Add a new key to the JWKS endpoint.
  2. Wait an hour (or more) to make sure PowerSync has the new key.
  3. Start signing new JWT tokens using the new key.
  4. Wait until all existing tokens have expired.
  5. Remove the old key from the JWKS endpoint.
⌘I