Update Auth Settings
/v1/auth/settingsorg.permission.securityorg.admin.securityThe API key or user must hold at least one of them. Legacy roles still work; prefer the others for new keys.
Updates authentication settings for the organization
Auth settings
Auth settings control how people sign in to your Kustomer org (with a Kustomer password, Google or SAML single sign-on) and how long their sessions last. A related endpoint returns the secret your server uses to verify chat customers' identity.
Each org has one auth settings record. It decides which sign-in methods the Kustomer login page offers your agents and admins, and how long a signed-in session lasts before they have to sign in again. Admins with security access change it in Kustomer's security settings. These settings affect people signing in to the agent desktop; they don't change how API keys or OAuth tokens work.
Sign-in methods
Each method is an object with an enabled flag. More than one can be on at once.
| Method | Meaning |
|---|---|
kustomer |
Email and password, managed by Kustomer |
google |
Sign in with a Google account |
saml |
Single sign-on through your identity provider |
The saml object also holds the identity provider's configuration: idpLoginUrl, idpLogoutUrl, idpIssuerId and idpPublicCerts (the provider's signing certificates), plus forceAuth, signRequests and allowUnencryptedAssert, which control re-authentication, request signing and whether unencrypted assertions are accepted.
Session length
app.userSessionExpirationMilliseconds sets how long a user session lasts, from 600,000 (10 minutes) to 2,592,000,000 (30 days).
Public and customer settings
Two related endpoints read other parts of the configuration:
GET /p/v1/auth/settingsneeds no authentication. It returns only which methods are enabled, which is what a custom login screen needs to decide which options to show.GET /v1/auth/customer/settings(needsorg.admin.apps, whichorg.adminincludes) returnssecret, the key your server uses to sign JSON Web Tokens that log customers in to Kustomer Chat. Anyone with it can sign in to chat as any customer, so keep it on your server. See Customer identity.
Which endpoint to use
| To | Call |
|---|---|
| Read the org's sign-in and session settings | GET /v1/auth/settings |
| Change sign-in methods, SAML configuration or session length | PUT /v1/auth/settings |
| Check which sign-in methods are enabled, without credentials | GET /p/v1/auth/settings |
| Get the chat identity signing secret | GET /v1/auth/customer/settings |
PUT /v1/auth/settings requires kustomer and google in every request, so read the current settings first, change what you need, and send the whole object back. Test SAML sign-in while password sign-in is still enabled before you turn password sign-in off. Reading and changing auth settings needs org.admin.security or org.permission.security.
Request body
application/jsonResponses
OK