> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/administration/sso-and-authentication.md).

# SSO & Authentication

## 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

{% hint style="info" %}
**Who is this for?** Organization administrators and security owners who control how users and automation authenticate to ContextQA.
{% endhint %}

Open **Settings → Authentication Configuration** (`/settings/auth`) to review the login modes available in the current organization.

![ContextQA Authentication Configuration showing No Auth, User Name and Password, and Google SSO options while keeping API credentials outside the screenshot](/files/QYv2TB738eOBI8mOaAU0)

## Authentication options

The current configuration page exposes these organization-level modes:

| Mode                       | Purpose                                                                                   | Operational guidance                                                                                                      |
| -------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **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.

{% hint style="warning" %}
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.
{% endhint %}

## Safe change procedure

1. Record the current enabled modes and the reason for the change.
2. Confirm that at least two administrators have a tested recovery path.
3. Configure the new method without disabling the known-good method.
4. Test sign-in in a separate private browser session with a non-owner account.
5. Verify that the user receives the intended role and workspace access.
6. Disable the old method only after successful testing and approval.
7. 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](/administration/api-tokens.md) 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

* [Roles & Permissions](/administration/roles-and-permissions.md)
* [Team Management](/administration/team-management.md)
* [System Configuration](/administration/system-configuration.md)
* [MCP server authentication](/mcp-server/authentication.md)

{% hint style="info" %}
**Need an authentication review?** [Book an Enterprise Demo →](https://contextqa.com/book-a-demo/)
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/administration/sso-and-authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.