Logto's authorization system and its use in identity management scenarios

Logto serves not only as an authentication provider but also as an authorization provider. In this article, I'll provide an overview of Logto's authorization methods and explain how these flexible layers can be applied to various scenarios.

Use role-based access control to protect your API resource#

Register API resources in Logto#

To establish an authorization system where different users have varying access to resources and action permissions, you can start by registering the API resource in Logto and then add permissions. Utilize roles to aggregate these permissions, whether for a single API or across multiple ones.

A great feature of Logto is its ability to create various types of roles that can be applied to different entities, including both user and machine-to-machine apps. Users can inherit user-specific roles, while machine-to-machine apps can inherit roles designed for them.

Targeted entity: User#

If your app is a general application where different users need to perform different actions, utilizing user roles is a flexible way to establish an effective access control system.

Targeted entity: Machine-to-machine app#

Machine-to-machine (M2M) is a common practice to authenticate if you have an app that needs to directly talk to resources. E.g., an API service that updates users' custom data in Logto, a statistic service that pulls daily orders, etc.

Machine-to-machine apps can be utilized in two key use cases in Logto:

1. Protect your headless API app by setting up an authorization system.
2. Use the Logto management API to develop your services, such as enabling user profiles that allow end users to update their identity-related information.

The distinction with user roles in this context is that the role is defined specifically as a machine-to-machine role, not a user role, and it can only be assigned to machine-to-machine apps.

In this API RBAC context, API resources, roles, and permissions are "democratized" and viewed at the system level within a unified identity system. This approach is quite common in straightforward B2C products, where there is less need for complex hierarchical management.

Use organization template (RBAC) to protect your organization-level resource#

In B2B scenarios, user roles can vary across different organizations. For instance, John might have an admin role in Organization A but only hold a member role in Organization B.

This can be achieved by setting up organization templates in Logto, which aids your multi-tenant app in building an access control system.

Rather than creating numerous roles for each organization, Logto enables you to create an organization template. This approach maintains consistency across all organizations while allowing users the flexibility to have different roles in different organizations.

The organization permissions do not require an API resource to be registered. Logto issues organization tokens that include roles and other claims, which can be used for further verification of the organization token in your API.

Use an organization template (RBAC) to protect both the system and organization-level resources#

If you have API resources registered in Logto and are looking to extend their use to the organization level, it's entirely possible.

This need may arise if you're using the same endpoint for both system-level functions and organization-specific operations. Having a single endpoint is fine, and utilizing organization context can also effectively ensure tenant isolation.

In Logto, you can assign API permissions directly to an organization's role, tailoring it to your specific requirements.

Here's a quick look at how to integrate API permissions with your organization's role.

This feature is in development and is expected to be available in the first half of 2024.

Excited about Logto authorization systems and our upcoming authorization features? Sign up today and get the latest product updates right away.