JWT Web Login
GET /account/tokenLogin.do
Opens the web drive as an identified user in a private deployment with JWT login enabled. It establishes a web session, not a business API access_token.
URL Query Parameters
| Parameter | Requirement and meaning |
|---|---|
userToken |
Required signed JWT from a trusted server, carrying the user's email, phone or babelId information |
fileId |
Optional target file/folder; otherwise opens the user's root |
onlyFileList |
A value of 1 displays only the file list and hides other channels |
closeTitleBar |
1 hides the title bar; default 0 |
disableEntMark |
1 hides the enterprise mark; default 0 |
disableUserMark |
1 hides the user settings entry; default 0 |
defaultLang |
cn, en or zh-HK; default cn |
defaultClrTheme |
normal or dark; default normal |
/account/tokenLogin.do?userToken=<JWT_TOKEN>&fileId=<FILE_ID>&onlyFileList=1Identity and Security
Supported user identifiers are confirmed as email (email), phone number (phone) and employee ID (babelId). This identity information is carried in the JWT passed as userToken, separately from the developer-authorization jwt_token.
The following email-login claims are confirmed for the current deployment (identity and timestamp are illustrative):
{
"duration": 60,
"payload": {"email": "user@example.com"},
"time": 1790000000000
}time is the Unix timestamp in milliseconds when userToken is generated; duration is the JWT's lifetime in seconds. The example 60 means 60 seconds, not a fixed value or default. Email belongs in payload.email; do not put a phone number or employee ID into the email field. This structure is confirmed for the current deployment. See JWT claims and validity.
Signing authenticates the JWT but does not encrypt its payload. Generate short-lived credentials only on a trusted server, use HTTPS and control URL logging. Validate the caller's authority to act for the target user.
Hiding UI elements does not grant permissions and does not replace access control.