SSO & Authentication
Configure ContextQA login modes safely, understand Google SSO availability, and protect the API credentials displayed in Authentication Configuration.
Quick answer
Configure ContextQA login modes safely, understand Google SSO availability, and protect the API credentials displayed in Authentication Configuration. Follow the documented prerequisites and steps, then verify the expected result before using the workflow in a shared or production process.
What this page covers
Open Settings → Authentication Configuration (/settings/auth) to review the login modes available in the current organization.
Authentication options
The current configuration page exposes these organization-level modes:
No Auth
Allows access without the normal user authentication flow when the deployment supports it
Use only in an explicitly approved, isolated environment; do not enable for an internet-accessible or shared organization
User Name and Password
ContextQA-managed login for users or controlled automation identities
Enforce the organization's credential policy and store automation credentials in an approved secret manager
Google SSO
Delegates human sign-in to Google when configured
Verify the permitted Google organization, account lifecycle, and emergency access procedure before enabling
An enabled mode displays an active switch. Select View Details to review its configuration. Do not change or disable a working authentication method until another administrator has tested the replacement in a separate session.
Enabling No Auth can remove an important access boundary. Treat it as an exceptional setting for an isolated environment, not a shortcut for user or service-account setup.
Safe change procedure
Record the current enabled modes and the reason for the change.
Confirm that at least two administrators have a tested recovery path.
Configure the new method without disabling the known-good method.
Test sign-in in a separate private browser session with a non-owner account.
Verify that the user receives the intended role and workspace access.
Disable the old method only after successful testing and approval.
Review the System Audits page for the resulting configuration event when available.
API details and secrets
The Authentication Configuration page also displays an API Details section containing an API key and a primary secret key. These values authenticate automated access and must be treated as production credentials.
Never paste them into documentation, test steps, screenshots, tickets, chat, or source control.
Never use a personal administrator credential in a shared CI/CD configuration.
Store secrets in a provider such as an approved vault or the CI/CD system's protected secret store.
Limit access to the users and jobs that require it.
Rotate a credential immediately if it is exposed.
Update dependent automation in a coordinated change so rotation does not silently stop release gates.
The documentation screenshot deliberately ends before the API credential values. When creating internal runbooks, follow the same pattern.
For scoped, per-integration credentials that a script or CI job uses to call the ContextQA REST API, create an API token rather than sharing these organization-level secrets.
User access after authentication setup
Authentication determines how a person proves identity. Roles determine what that person can do after sign-in.
Use Settings → User Management to invite users, verify their state, and assign roles. Use the Roles & Permissions tab to create the least-privilege roles required by the organization.
Each ContextQA organization uses its own subdomain and session. Signing in to one organization does not automatically grant access to another. Use the organization switcher only for organizations to which the account has already been granted access.
SSO availability
The observed demo workspace exposes Google SSO. Other enterprise identity-provider options can vary by deployment, subscription, or enabled feature set. If a required SAML or automated-provisioning control is not displayed on the Authentication Configuration page, confirm availability with the ContextQA account team before documenting or planning an implementation.
Do not reuse generic SAML values or guessed callback URLs. Identity-provider setup must use the metadata and endpoints displayed for the target ContextQA deployment.
Troubleshooting
Users cannot see the expected application areas: Confirm their workspace membership and assigned role. Successful authentication does not imply administrative permission.
Google sign-in succeeds but the user cannot enter the organization: Confirm that the correct Google identity was used and that the user exists in the organization's User Management page.
Automation stopped after credential rotation: Update the protected secret in every dependent pipeline or MCP connection, then run a controlled authentication check. Do not restore an exposed credential.
An administrator may be locked out: Do not toggle additional authentication modes. Use the tested recovery administrator or contact the deployment owner/ContextQA support.
Related pages
Last updated
Was this helpful?