PowerSync Service v1.26.1 — Safe access revocation with asynchronous ACL replication

[vesabric-hub]

Hello PowerSync team,

We are evaluating self-hosted PowerSync Service v1.26.1 with Flutter SDK v2.4.0 for an offline-first application.

PostgreSQL is our authoritative source of access permissions (ACL). We are considering a trusted backend/gateway in front of PowerSync Sync Streams.

We need to handle the following scenario:

User U3 initially has permission to access two independent data objects, H1 and H2.

An access administrator revokes U3's permission for H1 in PostgreSQL.

U3 retains permission for H2.

U3's previously issued JWT is still valid.

PowerSync's replicated ACL data may temporarily still contain the revoked H1 permission.

Our security requirement: A new Sync Stream connection after revocation must not expose H1, even if the replicated ACL state is stale. Access to H2 may resume once the relevant authorization state is confirmed to be consistent.

We are considering two possible solutions.

Option A — Trusted authorization scope

Can a trusted gateway issue or forward a server-signed JWT containing the current authorized object set {H2}, and can PowerSync v1.26.1 enforce that set across all relevant Sync Streams, including default and explicitly requested subscriptions, independently of stale replicated ACL data?

Is there a supported mechanism using trusted JWT claims or server-controlled parameters that cannot be overridden by client-supplied stream or subscription parameters?

Option B — Replication consistency barrier

Can a trusted backend determine that a specific PostgreSQL ACL revocation has already been applied to the parameter lookups used by PowerSync's active sync configuration?

We found checkpoint, LSN and parameter lookup mechanisms in the v1.26.1 source code and documentation.

Is there a supported interface that allows the backend to correlate a specific PostgreSQL revocation commit with the active PowerSync checkpoint, and safely admit new connections only after the updated authorization state is reflected in the relevant parameter lookups?

How does this mechanism behave during replication delays, snapshots, restarts and sync configuration switches?

Requested guidance

For either approach, could you please provide:

The recommended, officially supported mechanism.

Relevant documentation, configuration examples or source code references.

Any known limitations specific to PowerSync Service v1.26.1.

We do not require remote deletion of previously downloaded data or instantaneous termination of already established streams. Those concerns are handled separately.

Our immediate goal is to validate a sound authorization architecture before implementing shared access in a production application.

Thank you!

[rkistner]

PowerSync fully relies on JWTs for this, and we'd recommend using short-lived JWTs for this use case - say around 1-5 minute expiry time.

Your "Option A — Trusted authorization scope" sounds like the model that PowerSync uses by default: The sync queries should trust the JWT claims via [Auth parameters]9https://docs.powersync.com/sync/streams/parameters#auth-parameters), and never use subscription parameters as an authentication mechanism.

It's not clear what exactly you have in mind with a trusted gateway here. But routing the JWT via the client should work fine for this as long as you use short expiry windows.

[simolus3]

PowerSync's replicated ACL data may temporarily still contain the revoked H1 permission.

If the ACL permission model is implemented in Sync Streams, note that the user wouldn't receive changes from H1 after the revoked permission. PowerSync always uses consistent snapshots for parameters and data, so users only ever see the last state of H1 they had access to before the permission was revoked.

Can a trusted gateway issue or forward a server-signed JWT containing the current authorized object set {H2}

To provide an example, including something like SELECT objects.* FROM objects, json_each(auth.parameter('authorized_object_set')) acl WHERE objects.id = acl.value should work (auth.parameter extracts value from a signed and validated JWT). You can further restrict or partition this with Sync Stream parameters, e.g. if a user should be able to subscribe to objects independently while also only seeing objects mentioned in their token.

and can PowerSync v1.26.1 enforce that set across all relevant Sync Streams, including default and explicitly requested subscriptions, independently of stale replicated ACL data?

If you derive the check from auth.parameter, it's independent of replicated ACL data. A way to make this consistent across all Sync Streams would be to put the filtered query joining json_each into a common table expression and then selecting from that instead of the original table.

Can a trusted backend determine that a specific PostgreSQL ACL revocation has already been applied to the parameter lookups used by PowerSync's active sync configuration?

As far as I'm aware, this is not currently possible. Even once the revocation has been processed by PowerSync, existing connections might still be busy syncing an older snapshot with an outdated but consistent ACL / data combination. As soon as the ACL change reaches a checkpoint forwarded to users, they no longer have access to H1. But this is an asynchronous process.