Skip to main content

OAuth 2.0 SSO

Use OAuth2 when your enterprise identity system provides authorization-code sign-in and a user-information endpoint.

Use OAuth2 when your enterprise identity system provides authorization-code sign-in and a user-information endpoint. Configure the same app's credentials, three endpoints, and user fields in QwenWork, then register the generated callback with the identity system.

Obtain the identity-system settings

SettingPurpose
Client ID and Client SecretIdentify and authenticate the app
Authorization endpointOpens user sign-in and authorization
Token endpointExchanges the authorization code for an access token
UserInfo endpointReads the authenticated user's profile
Scopes, token authentication, and PKCEMust match the identity app
Sanitized UserInfo JSONIdentifies the actual ID, name, email, and other paths

Enter credentials and endpoints

  1. Open Users → Authentication → SSO login and click Add identity provider.
  2. Select Generic OAuth2 / OIDC, enter a name, and set the protocol to OAuth2.
  3. Enter Client ID, Client Secret, and the required scopes. OAuth2 does not require an openid scope.
  4. Select token-endpoint authentication: Basic Auth sends app credentials in the header; Form Post sends them in the form. Set PKCE to S256 or disabled as required by the identity platform.
  5. Select how the UserInfo request carries its access token, and enter the authorization, token, and UserInfo endpoints.
 Admin console: OAuth2 credentials and endpoint settings. Token-endpoint authentication carries app credentials. UserInfo token transport carries the access token obtained after sign-in. Configure each independently.

Map the returned user fields

  1. Enter source names or dot paths in the mapping section. The input handles the user. prefix; do not repeat it.
  2. For a response such as {"profile":{"id":"u123","name":"Alex Chen"},"email":"alex@example.com"}, use profile.id, profile.name, and email.
  3. Choose a stable, unique external user ID, rather than a name that can change or be duplicated.
  4. Keep ID and name mappings and at least one of email, phone, employee number, or account. Paths are case-sensitive; array indexes and scripts are unsupported.
  5. For first-sign-in account creation, enable automatic creation and select a default department. Enable automatic seat assignment if required.

Save and register the callback

  1. Save the provider; its callback is generated after creation.
  2. Reopen it and copy the complete callback.
  3. Register that URL in the same identity app's allowed callbacks and save.
  4. Enable the provider, then enable SSO in Sign-in methods. Only one provider can be active.
  5. Ask an ordinary user to complete sign-in and verify the enterprise, account association, and returned profile.
Configuration validation diagnoses settings and endpoint responses. It does not verify complete sign-in, callback registration, or field mappings.

Diagnose the failing stage

StageCheck first
Sign-in page cannot openAuthorization endpoint and identity-app status
Cannot return after authorizationComplete callback registered in the same app
Token exchange failsCredentials, Basic Auth/Form Post, and PKCE
Profile retrieval failsUserInfo URL, token transport, and scopes
Association or automatic creation failsUnique ID, actual profile values, default department, and conflicts

Existing users and deleted records

SSO looks up current users by external user ID only. A conflict-free match signs in and keeps the existing profile and sync source. Conflicts in account, email, phone, or employee number reject sign-in. An unmatched ID follows the automatic-creation setting. If only deleted history matches, the old QID is not restored. Automatic creation off rejects sign-in; automatic creation on with conflict-free current data creates a new user and QID. The returned profile, default department, and current seat policy apply. Old roles, passwords, seats, and departments are not inherited; history remains. Return to: Users / Authentication / Authentication overview.