Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

🔖 Enhancement description

Add configurable mapping between OAuth provider groups (Azure AD, Google Workspace, Okta, GitHub) and Appwrite Teams, evaluated automatically during OAuth login.

Current behavior: Appwrite creates a session from OAuth but ignores the user's group memberships from the identity provider. Developers must separately call provider APIs (e.g., Microsoft Graph) from application code to check groups and manually manage Appwrite Team assignments.

Proposed behavior: In Console (Auth → Settings → OAuth Provider), admins configure a group-to-team mapping:

Provider Group ID Appwrite Team Role
bb9b19e0-... admin owner
a1b2c3d4-... developer member
(default) guest member

During OAuth login, Appwrite reads the groups claim from the ID token (or calls the provider's group API if unavailable), then adds/updates the user's team memberships automatically.

Optional toggle: "Deny login if user is not in any configured group"

🎤 Pitch

Group-based access control is standard in enterprise identity management. Every Appwrite project using enterprise SSO currently re-implements the same workaround: store provider API credentials in the app, call Graph API after session creation, manually sync teams.

This has real problems:

  • Provider API secrets live in the app layer instead of Appwrite
  • Sessions are created before group checks, creating a race condition
  • No automatic sync — membership only updates if the developer builds it
  • Every project duplicates the same logic

Auth0 (Actions/Rules), Keycloak (group-to-role mapping), and Firebase (custom claims from OIDC) all solve this natively. Adding this to Appwrite would eliminate application-side provider API calls, centralize credential management, and make Appwrite a stronger choice for enterprise SSO.

👀 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

You must be logged in to vote

Replies: 1 comment

Comment options

Hello @alexfreeman90,

Thanks for opening this up! Usually, with these kinds of underlying issues, the first step is double-checking if there is a minor version mismatch in your installed environment tooling vs the actual framework requirements.

Have you tried outright clearing the respective local build/cache directories, forcing a clean slate reinstall, and ruling out any implicit breaking changes from recent patches?

If you are still hitting the exact same bottleneck, dropping a minimal reproduction steps (or specifically the raw error logs) here usually gets it sorted out way faster by the maintainers.

Hope this helps point you in the right direction. Let me know if you make any progress!

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
💡
Ideas
Labels
product / auth Fixes and upgrades for the Appwrite Auth / Users / Teams services. product / messaging Fixes and upgrades for the Appwrite Messaging.
2 participants
Converted from issue

This discussion was converted from issue #11485 on March 09, 2026 21:14.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.