Skip to main content

OIDC SSO

OpenID Connect (OIDC) adds an identity token to OAuth 2.0.

OpenID Connect (OIDC) adds an identity token to OAuth 2.0. QwenWork checks its issuer, signature, and validity period, then uses its user identifier to associate the account.

Prepare an OIDC app

Ask the identity administrator for an authorization-code OIDC app, Client ID, Client Secret, discovery address, and signing algorithm. Scopes must include openid; add the scopes needed for name, email, and other profiles.

Create the provider

  1. Open Users → Authentication → SSO login and add a provider.
  2. Choose Generic OAuth2 / OIDC, enter a name, and retain OIDC as the protocol.
  3. Enter Client ID, Client Secret, and scopes.
  4. Match token-endpoint authentication and PKCE to the identity app.
  5. Choose the actual ID-token algorithm: RS256 verifies with signing public keys; HS256 verifies with the Client Secret.
 Admin console: OIDC credentials, algorithm, and discovery settings.

Obtain and check the endpoints

ModeConfiguration
Well-Known endpointEnter the supplied discovery-document URL, parse it, and check the returned endpoints
IssuerEnter the platform's published issuer and parse it
ManualEnter issuer, authorization and token endpoints, the algorithm's public-key endpoint, and UserInfo if needed
The issuer must match the ID token's iss, including its path and trailing slash. Obtain actual addresses from the identity administrator. Check Nonce and clock skew. Nonce links this request to the returned token and must be returned correctly when enabled. Allowed clock skew is 30–300 seconds; keep both systems' clocks synchronized.

Map users and register the callback

  1. Check sources in the mappings. External user ID usually uses user.sub; name and email default to user.name and user.email. Adjust supported sources if required.
  2. Keep ID and name and at least one of email, phone, employee number, or account.
  3. If creating users automatically, enable it and choose the default department. At least one usable identity value must be returned.
  4. Save, reopen the provider, and copy the generated callback. Register it in the identity app and save there.
  5. Enable the provider and SSO sign-in. Test with an ordinary user and check the account, name, and profile.
Configuration validation helps diagnose settings and endpoint responses; it does not prove complete sign-in, mappings, or user creation.

Troubleshooting

SymptomCheck
Discovery parsing failsReachability from the enterprise service and a valid OIDC discovery response
Issuer mismatchDiscovery issuer, saved issuer, and token iss
Signature failureRS256/HS256, public-key URL and key rotation, or Client Secret
Nonce or time failureReturned nonce, token validity, and system clocks
Empty name or emailScopes, actual claims, and mapped sources

Existing users and deleted records

SSO matches current users by external user ID only. Conflict-free matches preserve the current profile and sync source. Conflicts with another user's account, email, phone, or employee number reject sign-in. Unmatched IDs follow automatic creation. An ID found only in deleted history does not restore its old QID. With automatic creation off, sign-in fails. With it on and conflict-free data, a new user and QID use the current returned profile, default department, and seat policy. Old roles, passwords, seats, and departments are not inherited. History remains. Return to: Users / Authentication / Authentication overview.