Authentication allows web apps to identify the users who are accessing Feishu, so that the login process can be built for web apps.
Step 1: If a user is not logged in, Request authorization;
Step 2: When the user logs in, the Open Platform creates a login pre-authorization code, and starts a 302 redirect to go to the redirect URL;
Step 3: The web app calls the Get user_access_token API at the back end to verify if the login pre-authorization code is valid, and obtain the user_access_token;
Step 4: If other user information is needed, the Obtain user information API can be called at the back-end of the web app.
Users can directly access web apps via Feishu without login by scanning the QR code or entering their accounts and passwords.
Go to Developer Console, and then click "Create Custom App" to obtain app_id and app_secret.
Add a redirect URL in the Secure Domain configuration of the app, for example, https://open.feishu.cn/document. If it is not configured or is improperly configured, the Platform prompts an invalid request.
Create a request URL according to the description of the Request authorization API, so that the user can be redirected to the URL for authorization.Note that the parameter redirect_uri needs to be processed with URLEncode, for example:
https://open.feishu.cn/open-apis/authen/v1/authorize?app_id=cli_a219a18a64f8d01b&redirect_uri=https%3A%2F%2F127.0.0.1%2Fmock&scope=bitable:app:readonly%20contact:contact&state=RANDOMSTATE
If a company doesn't install the app, the following prompt appears:
After the user logs in to the app (by scanning the QR code or entering the account and password) in step 3, the Open Platform adds the parameters code and state to redirect_uri, and then requests the URL through redirection, as shown below:
https://127.0.0.1/mock?code=59bg7a22c77447bbb4c92bbd675954gg&state=RANDOMSTATE
Request the login authorization API through Postman (For details, see Obtain the logged-in user ID), and use the code in exchange for user_access_token and refresh_token. Note that the code is valid for 5 minutes and can only be used once.
Request header:
Parameter | Type | Required | Description |
---|---|---|---|
Authorization | string | Yes | app_access_token Value format: "Bearer Example value: "Bearer a-7f1bcd13fc57d46bac21793a18e560" |
Content-Type | string | Yes | Fixed value: "application/json; charset=utf-8" |
Request Body:
{ "grant_type":"authorization_code", "code":"xMSldislSkdK"}
Return Body:
{ "code": 0, "msg": "success", "data": { "access_token": "u-5Dak9ZAxJ9tFUn8MaTD_BFM51FNdg5xzO0y010000HWb", "refresh_token": "ur-6EyFQZyplb9URrOx5NtT_HM53zrJg59HXwy040400G.e", "token_type": "Bearer", "expires_in": 7199, "refresh_expires_in": 2591999, "scope": "auth:user.id:read bitable:app" }}
The user's access_token and refresh_token are returned along with thea corresponding valid duration field in step 5. Use the user_access_token to obtain the user information . The access to sensitive information requires the company's authorization.
The user_access_token and refresh_token have different validity periods, and the former's is shorter than the latter's. When the user_access_token expires, the refresh_token can be used to call the Refresh user_access_token API to obtain a new pair of user_access_token and refresh_token with the same validity periods as the previous pair. If a refresh fails, you can have a retry within the expiration date.