Practices and insights on implementing an invitation and role access management feature like Logto Cloud collaboration in a multi-tenant application.
Last week, we introduced the collaboration feature on Logto Cloud. If you missed it, take a look! Now, you can invite colleagues and co-workers to your existing Logto tenants, collaborating together on maintaining the identity system for your applications.
In this feature release, we've added two roles to each Logto tenant:
Consistent with our commitment to using our own tools, we've leveraged our RBAC (Role-Based Access Control) and Organizations feature in building user collaboration. If you're new to RBAC, check out our previous post to get started.
In this blog post, let's take a look at what went into implementing this feature, and how these practices might benefit you if you're developing multi-organization applications.
Each Logto Cloud tenant functions as an independent organization in our system, powered by our own Organizations feature. To introduce the tenant admin and collaborator roles, we created two organization roles in the organization template, each assigned with a specific set of organization permissions.
We've provided a set of invitation-related Management APIs in the organizations feature. With these APIs, you can, for example:
POST /api/organization-invitations create and send an organization invitation to an email addressGET /api/organization-invitations & GET /api/organization-invitations/{id} get your invitationsPUT /api/organization-invitations/{id}/status accept or reject the invitation by updating the invitation statusFor more details, refer to the full API documentation.
Since invitations are sent via email, ensure your email connector is properly configured. In this release, we introduced a new email template usage type, OrganizationInvitation, allowing customization of the invitation email template.
This email template will accept a {{link}} variable by default, which is the link to the Logto Console's landing page, where the users can accept the invitation and join a Logto tenant. One of the landing pages in Logto Cloud looks like the screenshot below:
Refer to the API documentation for more details about sending the invitation email through Management API.
With the above setups, we can send invitations via email, and invitees can join the organization with the assigned role.
Users with different organization roles will have different scopes (permissions) in their access tokens. Thus, both the client application (Logto Console) and our backend services should check these scopes to determine visible features and permitted actions.
Alright, so far everything seems connected, and what else do we miss?
Managing scope updates in access tokens involves:
In Logto Cloud, the Console actively checks user scopes using SWR requests, and we auto-consent whenever a user is promoted to admin.
If you're implementing a similar feature with RBAC, you'll need a mechanism (e.g., WebSocket or server-push events) to notify your application of scope updates, enabling re-consent or issuing new access tokens accordingly. Logto will also provide more webhooks to assist with this in future updates.
Logto Cloud's multi-tenancy and collaboration features leverage our Organizations feature. If you're developing a similar multi-tenancy app, consider utilizing this feature with similar approaches.
I hope this blog post proves insightful. For questions or discussions, feel free to join our Discord channel.