Plans for integrating WorkOS's FGA?

[LagBug]

WorkOS recently released it's own FGA implementation (https://workos.com/docs/fga).
Are there plans to support it in the component?

Thanks!

[ianmacartney]

Is the suggestion to sync all permissions into the component?

…

On Tue, Apr 14, 2026 at 8:16 AM LagBug ***@***.***> wrote: *LagBug* created an issue (get-convex/workos-authkit#43) <#43> WorkOS recently released it's own FGA implementation ( https://workos.com/docs/fga). Are there plans to support it in the component? Thanks! — Reply to this email directly, view it on GitHub <#43>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW43V4TDT7PCQJEFT734VZI5PAVCNFSM6AAAAACXZASWRCVHI2DSMVQWIX3LMV43ASLTON2WKOZUGI3DGMBTHEZTCOA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[LagBug]

Is the suggestion to sync all permissions into the component?
…

Not the individual permissions (those assigned to a specific resource ID), but maybe we could sync the global permissions(eg. billing:view, report:create, etc.)/resource types, and provide a typesafe interface to interact with?

Then we could use the component to query for if a subject has access to a resource, and we would enjoy all of the benefits typesafety provides there.

[ianmacartney]

Could this be decoupled to a separate component? So users could use one or both independently?

…

On Wed, Apr 15, 2026 at 5:37 AM LagBug ***@***.***> wrote: *LagBug* left a comment (get-convex/workos-authkit#43) <#43 (comment)> Is the suggestion to sync all permissions into the component? … <#m_-1932851510331797151_> Not the individual permissions (those assigned to a specific resource ID), but maybe we could sync the global permissions(eg. billing:view, report:create, etc.)/resource types, and provide a typesafe interface to interact with? Then we could use the component to query for if a subject has access to a resource, and we would enjoy all of the benefits typesafety provides there. — Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW6BEKFO5WI2I6BTF634V57B5AVCNFSM6AAAAACXZASWRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENJSGAZTCNRSGU> . You are receiving this because you commented.Message ID: ***@***.***>

[wt-lau]

I not sure how this can be implemented completely. Since WorkOS FGA docs recommend "For resource-specific permissions, call the authorization API". Calling an external API in queries and mutations are considered anti-pattern in Convex.

Unless if focus on just the syncing of roles and permissions, then maybe the same component will do.

Docs: https://workos.com/docs/fga/access-checks

[LagBug]

I not sure how this can be implemented completely. Since WorkOS FGA docs recommend "For resource-specific permissions, call the authorization API". Calling an external API in queries and mutations are considered anti-pattern in Convex.

Unless if focus on just the syncing of roles and permissions, then maybe the same component will do.

Docs: https://workos.com/docs/fga/access-checks
Could this be decoupled to a separate component? So users could use one or
both independently?
…

I do think that it'd make sense to have it here, though another component to be an option.
Is there any chance of having a more first-class Convex+FGA implementation down the line?
I quote the reply I got from WorkOS where I asked them about this, as it might be useful for future reference:

Convex + FGA. The first-class Convex integration is AuthKit-focused; there's no native Convex+FGA binding today. Practically: call the FGA Check API (https://workos.com/docs/reference/fga/access-check/check) from a Convex action on mutations, and for query-time reads (dashboards, list views) maintain a mirror table populated from your own app writes. FGA doesn't emit role-assignment events (https://workos.com/docs/events) today, so the sync has to be driven from your own writes rather than webhooks — every time your app calls the FGA assignments API, write the same delta to your mirror.

Modeling cross-org sharing. One thing to flag: FGA assignments (https://workos.com/docs/fga/assignments) today are always made to an organization_membership (a user within an org), not to org entities. So "grant Org B access to this report" can't be expressed as a single grant — you'd fan it out at the app layer, resolving Org B's current members and creating a report-scoped assignment per member. When Org B adds a member later, an organization_membership.created event triggers another grant. Org-as-subject and user groups are on the FGA roadmap (https://workos.com/docs/fga), which should make this cleaner down the line.

Application-layer for now. FGA permissions are additive with no subset primitive, so when Org B's admin grants a member access to a shared report, your app needs to look up the ceiling you stored at share time and clamp the grant before calling the assignments API. For read-time auditing, list effective permissions (https://workos.com/docs/reference/fga/access-check/list-effective-permissions) returns every permission a membership has on a resource (direct + inherited), useful for catching anything that slipped past your ceiling logic.

"Show me all reports I can see." List resources for a membership (https://workos.com/docs/reference/fga/access-check/list-resources) does this. One caveat: indirect assignment lookups (https://workos.com/docs/fga/resource-discovery) aren't supported yet, so the endpoint returns only resources where the user has a direct assignment on the parent or child. If your dashboard relies on inherited perms (workspace-admin seeing all reports), you'll want direct report-level assignments in your fan-out anyway, which dovetails with the cross-org approach above.

[ianmacartney]

What is the big benefit of using FGA vs. having your own roles & groups tables? e.g. if you already have a notion of organizations of users within your app, and you have logic to look up if a user is in the right group, then FGA seems redundant? Is the big win the WorkOS dashboard, or convenience with other integrations? I suspect FGA is a good fit for getting started / for the convenience of not setting up some tables, but compared to using something like `convex-authz` or doing something yourself, I'd love to know what capabilities it unlocks

…

On Tue, Apr 21, 2026 at 2:54 PM LagBug ***@***.***> wrote: *LagBug* left a comment (get-convex/workos-authkit#43) <#43 (comment)> I not sure how this can be implemented completely. Since WorkOS FGA docs recommend "For resource-specific permissions, call the authorization API". Calling an external API in queries and mutations are considered anti-pattern in Convex. Unless if focus on just the syncing of roles and permissions, then maybe the same component will do. Docs: https://workos.com/docs/fga/access-checks Could this be decoupled to a separate component? So users could use one or both independently? … <#m_3375474398385109843_> I do think that it'd make sense to have it here, though another component to be an option. Is there any chance of having a more first-class Convex+FGA implementation down the line? I quote the reply I got from WorkOS where I asked them about this, as it might be useful for future reference: Convex + FGA. The first-class Convex integration is AuthKit-focused; there's no native Convex+FGA binding today. Practically: call the FGA Check API (https://workos.com/docs/reference/fga/access-check/check) from a Convex action on mutations, and for query-time reads (dashboards, list views) maintain a mirror table populated from your own app writes. FGA doesn't emit role-assignment events (https://workos.com/docs/events) today, so the sync has to be driven from your own writes rather than webhooks — every time your app calls the FGA assignments API, write the same delta to your mirror. Modeling cross-org sharing. One thing to flag: FGA assignments ( https://workos.com/docs/fga/assignments) today are always made to an organization_membership (a user within an org), not to org entities. So "grant Org B access to this report" can't be expressed as a single grant — you'd fan it out at the app layer, resolving Org B's current members and creating a report-scoped assignment per member. When Org B adds a member later, an organization_membership.created event triggers another grant. Org-as-subject and user groups are on the FGA roadmap ( https://workos.com/docs/fga), which should make this cleaner down the line. Application-layer for now. FGA permissions are additive with no subset primitive, so when Org B's admin grants a member access to a shared report, your app needs to look up the ceiling you stored at share time and clamp the grant before calling the assignments API. For read-time auditing, list effective permissions ( https://workos.com/docs/reference/fga/access-check/list-effective-permissions) returns every permission a membership has on a resource (direct + inherited), useful for catching anything that slipped past your ceiling logic. "Show me all reports I can see." List resources for a membership ( https://workos.com/docs/reference/fga/access-check/list-resources) does this. One caveat: indirect assignment lookups ( https://workos.com/docs/fga/resource-discovery) aren't supported yet, so the endpoint returns only resources where the user has a direct assignment on the parent or child. If your dashboard relies on inherited perms (workspace-admin seeing all reports), you'll want direct report-level assignments in your fan-out anyway, which dovetails with the cross-org approach above. — Reply to this email directly, view it on GitHub <#43?email_source=notifications&email_token=AACZQW2H2JEIWNXSHIDWLPD4W7UZLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZGIYDOMJWGA2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4292071604>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACZQW2CD4LGOSH3ONM6PCD4W7UZLAVCNFSM6AAAAACXZASWRCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOJSGA3TCNRQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[LagBug]

What is the big benefit of using FGA vs. having your own roles & groups
tables? e.g. if you already have a notion of organizations of users within
your app, and you have logic to look up if a user is in the right group,
then FGA seems redundant? Is the big win the WorkOS dashboard, or
convenience with other integrations? I suspect FGA is a good fit for
getting started / for the convenience of not setting up some tables, but
compared to using something like convex-authz or doing something
yourself, I'd love to know what capabilities it unlocks
…

Generally, I'd prefer to have as little maintenance as possible for something as critical as authorization.
Another thing would be if in the future we want to migrate away from Convex (highly unlikely tho), we don't have to migrate our authorization as it'd live on WorkOS.

We are currently evaluation FGA and convex-authz, and the only thing I'm concerned about with the latter is that it's not by Convex, and can't be sure about it being maintained long term or it's security.

[wt-lau]

Thanks for sharing convex authZ @ianmacartney !

So far based on what I see, the functionalities are pretty complete. One concern I have is the WorkOS SSO sync / flow that might be tricky. Will cycle back once I have tested it thoroughly.

[wt-lau]

Hi, I have did some testing would like to share my findings.
I think the biggest issue of integrating WorkOS + convex-authz is that there are 2 systems to manage. This creates unnecessary overhead and complexity. And I really like how WorkOS' implementation of FGA is so simple.
WorkOS gives devs the necessary tools to enable their customers to create their authz strategy according to their needs, but convex-authz lacks all these features.

My only concern now is how can I adopt WorkOS FGA without breaking Convex's reactivity (due to the need to call external APIs via actions).

[ianmacartney]

Thanks for the updates. This part isn't clear to me, but I haven't dug into FGA deeply:

to enable their customers to create their authz strategy according to their needs, but convex-authz lacks all these features

I'd be curious what features you'd want to reflect in Convex - in this component, another dedicated component, or from a library / in your own tables.

My gut is that generally security rules end up being tightly coupled with business logic, and most companies will end with their own mostly-simple-with-a-few-special-cases abstraction for this. I think it's very normal to have your own table with memberships or roles, etc.
I also understand the desire to use something off-the-shelf, to not re-invent the wheel. I know we're in the early-ish days of third-party components, so the non-Convex ones don't have a long track record yet. Being able to audit the source of the authz library is reassuring, and you can always fork / vendor parts of it in if you want stability and control, without rolling your own