Overview of app permissions and approval rules

Overview of app permissions and approval rules

3 min read
I. Intro
🔖
Who can perform these steps: Primary administrators or administrators with all applications management permissions.
For app release approval rules, administrators can set review-required permissions for developers to reduce the review cost and improve the review efficiency.
This article provides references and suggestions to administrators regarding the type and level of app permissions and the approval rules recommended by the platform.
II. Description
1. Types and levels of app permissions
App permission is a control mechanism that uses the server API provided by Lark to get or modify data within the organization, such as obtaining the organizational structure, managing personnel onboarding and offboarding, updating docs, sending messages, and so on.
Lark has designed corresponding app permissions for each API, and different app permissions can access or manage different organization data.
After the app is submitted for release, the organization administrator can review the app permissions. After approval, the app can call the server API or listen to the subscribed event list. For all available permissions within the organization, see scope list.
Administrators can determine whether to set permissions that do not involve sensitive data to be automatic approval permissions based on app permission type and app permission level.
1.1 Types of app permissions
Based on the identity used when calling the API, app permissions can be divided into two types:
250px|700px|reset
  • App identity permission: The API is called through the Tenant Access Token where the range of data resources that the API can manage is determined by the app's data permission range.
  • Note: If your business scenario does not need to manage user data resources and only requires managing resources owned by the app (for example, creating docs in the app's dedicated directory), we recommend using the Tenant Access Token. Then there is no need to request additional authorization when calling the API.
  • User identity permission: Calls the API through the User Access Token where the range of data resources that the API can manage is determined by the permission range of the user identity.
Permission type
Description
Scenario example
App identity permission (tenant_access_token)
When calling an API or subscribing to events with "tenant_access_token", the app must have app identity permission.
For example, if an app named "My bot" uses "tenant_access_token":
  • When calling the interface to create a Base, the owner of the newly created Base is "My bot".
  • When subscribing to Docs events, the app can only subscribe to changes in Docs owned or administered by "My bot". It cannot receive notifications for changes to other Docs.
User identity permission (user_access_token)
When calling an API or subscribing to events with "user_access_token", the app must have user identity permission.
For example, if an app named "My bot" uses "user_access_token" for a user named "Lily" :
  • When calling the interface to create a Base, the owner of the newly created Base is "Lily".
  • When subscribing to Docs events, the app can only subscribe to the changes in Docs owned or administered by "Lily". It cannot receive notifications for changes in other Docs.
1.2 Levels of app permissions
App permissions can be divided into two levels based on the types:
  • Non-sensitive permissions: The sensitivity of the data accessed by this permission is low, such as accessing app ID, app configuration, interface name, and other data needed for app running. So no review is required, and it takes effect immediately after applying.
  • Advanced permissions: The sensitivity of the data accessed by this permission is high, such as accessing documents, Calendar events, Messenger messages, profile photos, geographical location, and other data involving content and personal information. The request must be sent for review, and it can only take effect after being approved by the app administrator.
  1. Recommended review rules
Based on the type and level of app permissions, the platform recommends the following review rules. For specific information about the API, see Server API list.
Permission level/type
App identity
User identity
Non-sensitive permissions
These permissions do not involve sensitive organization information and can be set as automatic approval.
Advanced permissions
These permissions involve sensitive organization information and require reviews.
Note: If not for a significant reason, the request for advanced permissions will not get approval.
Among these permissions, the app acts on behalf of the user. The user needs to grant permission to the app before using the app. Therefore, except for specific sensitive permissions, most permissions can be set as automatic approval.
Note: Specific sensitive permissions, such as contacts and messages, need to be reviewed to enhance organization security.
Written by: Lark Help Center
Updated on 2025-01-17
How satisfied are you with this content?
Thank you for your feedback!
Need more help? Please contact Support.
0
rangeDom