Skip to content

Commit 44e35af

Browse files
louischan-ourskylouischan-oursky
committed
Add research result on Clerk
1 parent 451851b commit 44e35af

3 files changed

Lines changed: 87 additions & 12 deletions

File tree

‎docs/specs/organization/00-index.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,5 +10,6 @@ Read the following documents for detailed study on each competitor
1010
- [FushionAuth](./04-fushionauth.md)
1111
- [SuperTokens](./05-supertokens.md)
1212
- [Zitadel](./06-zitadel.md)
13+
- [Clerk](./07-clerk.md)
1314

1415
The design draft is at [./10-draft.md](./10-draft.md).

‎docs/specs/organization/01-comparison.md‎

Lines changed: 23 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -6,16 +6,16 @@
66
> [!IMPORTANT]
77
> SuperTokens is not included in this table because it does not natively support organization at all.
88
9-
| Item | Auth0 | Stytch | Zitadel |
10-
| --- | --- | --- | --- |
11-
| Organization is optional | Yes | Authentication Type is determined at project creation. Unmodifiable. | No |
12-
| Support building GitHub-style service | Yes | Have to emulate with 2 projects | Yes |
13-
| Different password policies | Yes | Either Cross-organization or Organization-scoped. Once chosen, no going back | Yes |
14-
| Different MFA policies | Use post-login action to customize | Yes | Yes |
15-
| IAM | Yes | Yes | Yes |
16-
| Invitation | Yes. Can return to specific application | Only supported at API level. Can return to specific URL to your backend | Yes when V2 API is enabled. Cannot return to URL |
17-
| Email discovery | Yes | Yes | No |
18-
| Organization switcher | No. Session bound to single org | Provide API for self-implementation | No |
9+
| Item | Auth0 | Stytch | Zitadel | Clerk |
10+
| --- | --- | --- | --- | --- |
11+
| Organization is optional | Yes | Authentication Type is determined at project creation. Unmodifiable. | No | Yes |
12+
| Support building GitHub-style service | Yes | Have to emulate with 2 projects | Yes | Yes |
13+
| Different password policies | Yes | Either Cross-organization or Organization-scoped. Once chosen, no going back | Yes | No |
14+
| Different MFA policies | Use post-login action to customize | Yes | Yes | No |
15+
| IAM | Yes | Yes | Yes | No |
16+
| Invitation | Yes. Can return to specific application | Only supported at API level. Can return to specific URL to your backend | Yes when V2 API is enabled. Cannot return to URL | Yes |
17+
| Email discovery | Yes | Yes | No | No |
18+
| Organization switcher | No. Session bound to single org | Provide API for self-implementation | No | Yes |
1919

2020
## Implications
2121

@@ -24,29 +24,39 @@
2424
In all competitors, a sign-in session is bound to a single organization only.
2525
In Stytch, organization switching is done with token exchange.
2626

27+
In Clerk, the end-user can just switch organization without signing-in again.
28+
2729
### GitHub-style service
2830

2931
IMO, Auth0 is the most easiest to work with.
3032
It does not enforce that an organization must exist, and does not enforce that users must belong to one and only one organization.
3133
It just models GitHub-Style service naturally.
3234

35+
Clerk also models this easily.
36+
3337
### Different password policies and different MFA policies
3438

3539
In Auth0, password policies to tied to the connection, while MFA is a project-wide setting.
3640
In competitors where organization is mandatory and user belonging to a single organization, all these authentication settings are tied to the organization.
3741

3842
IMO, authentication settings should be organization-overridable.
3943

44+
Notably, Clerk does not support this.
45+
4046
### IAM
4147

4248
In all competitors, the IAM use case is trivial to implement.
4349
We should consider that in our design.
4450

51+
Notably, Clerk does not support this.
52+
4553
### Invitation
4654

4755
It seems that invitation is not very well implemented among competitors.
4856
Auth0 does the best in this area.
4957

58+
Clerk supports this quite well, given that it is not OIDC-based, and it literally just allows you to specify `redirect_uri`.
59+
5060
### Email discovery
5161

5262
Again Auth0 does the best here.
@@ -57,8 +67,9 @@ At the end you have to try out the example app to test it out yourselves.
5767

5868
### Organization switcher
5969

60-
No competitors support this out-of-the-box.
61-
6270
In particular, Auth0 does not report to the client application that how organization the user belong to.
6371

6472
In other competitors where a user belongs to one and only one organization, you have to do it yourselves.
73+
74+
Only Clerk supports this out-of-box, but given its lack of support of different password policies and different MFA policies,
75+
it is not very useful.

‎docs/specs/organization/07-clerk.md‎

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
# A brief research on how Organization works in Clerk
2+
3+
This document is valid as of 2025-06-09.
4+
5+
## Concepts
6+
7+
Clerk does not build on top of OIDC, so it does not have things like OIDC client applications.
8+
9+
### Application
10+
11+
- An application has its own domain.
12+
13+
### Organization
14+
15+
- Organization is off by default.
16+
- Once it is turned on, every user is allowed to create organization by default.
17+
- Organization does not have specific settings, e.g. password policy.
18+
19+
### User
20+
21+
- A user can belong to no organization.
22+
- A user can belong to multiple organization.
23+
24+
## How to do usecase X
25+
26+
### Usecase 1: Different password policies
27+
28+
Not possible. It is because organization does not have specific settings.
29+
At least I did not see it in the dashboard.
30+
Checking the API documentation does not reveal something similar.
31+
See https://clerk.com/docs/references/backend/organization/update-organization
32+
33+
### Usecase 2: IAM
34+
35+
Not possible. It is because email address has to be globally unique.
36+
It is not possible to create an IAM user that shares the same address with a user in the global user pool.
37+
38+
### Usecase 3: Different MFA policies
39+
40+
Not possible. The reason is the same as that of different password policies.
41+
42+
### Usecase 4: Invitation
43+
44+
See https://clerk.com/docs/organizations/invitations
45+
46+
The invitation must target an email address.
47+
The invitation can optionally take `redirect_uri` which allows to redirect the user.
48+
49+
### Usecase 5: Email discovery
50+
51+
The prebuilt <SignIn> component does not offer a way to select organization on sign in.
52+
The active organization is taken from the last active one.
53+
The last active one is the one selected by the end-user in the <OrganizationSwitcher> component.
54+
55+
In this sense, it does not really support the typical email discovery.
56+
57+
### Usecase 6: Organization Switcher
58+
59+
It supports a prebuilt <OrganizationSwitcher> component in the NextJS SDK.
60+
61+
However, due to the fact that it does not support organization specific settings,
62+
switching organization is just about switching the last active org ID.
63+
It does not do things like authenticate again if the specific organization requires MFA.

0 commit comments

Comments
 (0)