Articles in this section

Set up authentication for an MCP server

The Access tab replaces the Access token tab. You can use this tab to manage how users and clients authenticate with an MCP server.

You can select Celigo Identity as the built-in identity provider, or Token validation to have Celigo validate tokens your IdP issues. You can also use API tokens for non-interactive access. API tokens are available regardless of the identity provider you select.

Acces tab_new.png

Prerequisites

  • You must have an admin role in the Celigo account.
  • If you use Token validation, you need the Issuer URL and Audience from that provider.
  • You can optionally provide a Client ID and Client Secret, but they are required only when Introspection is selected as the token validation method.
  • Get your MCP client installed (Cursor or Claude).

Authentication options

Celigo MCP servers offer two OAuth-based identity provider modes alongside API token authentication. You can enable both OAuth and API tokens simultaneously on a single server.

  • Authentication

    • Celigo Identity (default): Uses Celigo login credentials; if SSO is active, users are automatically routed to your provider. This is the recommended option because it requires zero configuration, supports transparent SSO (Google Workspace, Okta, Azure AD, and any SAML/OIDC provider), enables per-user access management directly in Celigo, and is required for upcoming per-user connection features. New MCP servers using Celigo authentication are ready to accept OAuth connections immediately with no additional setup required.
    • Token validation: Authenticates via third-party providers (for example, Auth0, Okta) with permissions managed through the IdP. Use this option only if your organization has a specific requirement to authenticate MCP connections through a dedicated external IdP that is separate from your Celigo SSO configuration. Note that with Token validation, the Users section is hidden (access is managed at the IdP level), per-user usage visibility is limited, and upcoming per-user connection features will not be available.

    Tip

    If your organization requires SSO, you don't need the Token validation option for that. Celigo authentication already supports SSO when a user signs in with their Celigo credentials and your account has SSO configured, they are automatically redirected to your SSO provider. If you are unsure which option to choose, use Celigo Identity.

  • API Token: Uses a fixed bearer token for authentication, bypassing interactive login screens. This is best for automation, service accounts, or legacy clients lacking OAuth support.

Authentication - configure your provider

By default, all new MCP servers use Celigo Identity. Perform the following steps to switch providers:

authentication_access tab_mcp.png

Important

When Token validation is selected, the Access tab no longer displays the Users list, as your IdP manages all access permissions. Furthermore, individual per-user logins (such as Gmail or Salesforce) aren't supported with Token validation.

Select an identity provider
  1. Go to AI studio → MCP servers and select the server.
  2. In the Access tab. On the left, by default, the Authentication tab is selected.
  3. You can configure either of the following authentication Type under Identity provider:

    • Celigo Identity: When you select Celigo Identity, the Access tab displays Users, Groups, and Roles tabs to manage access to the MCP server.

      • Users: Displays end users with access to the MCP server and the following details:
        • Name: The end user's name.
        • Email: The end user's email address.
        • Access via: Shows how the end user receives access to the MCP server:

          • Direct: Access assigned directly to the end user.
          • Group name: Access inherited through a group.
          • Role name: Access granted through an assigned role.
          • —: No access source is displayed.

          Multiple entries appear when access is granted through more than one source. Select the + Assign roles entry to see the roles and the capabilities they grant. 

        • Remove: Select the delete icon to remove the end user's assignment to the MCP server.
      • Groups: Displays assigned groups with their Name/Description and Users count, and a Remove column.
      • Roles: Displays assigned roles with their Name/Description and Users count, and a Remove column.

      You can search for assignments, assign additional users, groups, or roles, and remove existing assignments from the corresponding tab by selecting the delete icon in the Remove column.

      authentication tab.png

      To assign users, groups, or roles:

      1. Go to AI studio > MCP servers, and open the MCP server.
      2. Select Access > Authentication. Make sure Celigo Identity is selected.
      3. Select the required tab:
        • Users: Select Assign users.
        • Groups: Select Assign groups.
        • Roles: Select Assign roles.
      4. In the Users, Groups, or Roles step, search for and select the users, groups, or roles you want to assign.
      5. In the Capabilities step, select the capabilities to grant access to. Use Capability sets, Tools, APIs, Prompts, and Resources to find them.
      6. Select Save & close. 

      For more information about managing access, see Invite and manage end users, Create and manage end user groups, and Create and manage end user roles.

    • Token validation: Previously, you entered external IdP settings separately on each MCP server. Now, you configure an external IdP once at the account level and reference it from any MCP server.

      1. If you have previously created a user, use the Token Validation drop down to select an existing IDP.

        Or

      2. Click Create external provider to add a new one and enter the required details:

        • Name: Name your external provider.
        • Issue URL: The expected token issuer (iss). Copy this from a real access token issued by your IdP.
        • Audience: The expected token audience (aud). The MCP server accepts tokens only if their audience matches this value.
        • Token validation: Select how an MCP server validates access tokens.

          • JWKS (JSON web key set): Validates JWT access tokens locally using the issuer’s JWKS. Requires JWT access tokens.
          • Introspection: Validates tokens by calling the issuer’s introspection endpoint. Use this for opaque tokens or revocation-sensitive setups. Requires Client ID (required) and Client Secret (optional).

            Introspection.png

            Client ID and Client secret (Introspection only): Credentials used by an MCP server to authenticate the issuer’s introspection endpoint. Store these securely and rotate them if exposed.

        • Permissions: Select the permissions this MCP server requires.

          • mcp:read: Allows read-only / non-destructive MCP operations.
          • mcp:write: Allows operations that may change data or state.

            Important

            The token must include the required scopes (commonly in a scope or scp claim, depending on IdP). If a token is valid but missing required scopes, access will be denied.

      3. Click Save & close.The newly created external provider name is displayed in the External provider field. You have options to Edit or Delete the selected provider.

        External_provider_list.png
      4. Click Save & close.

Limitations - Known provider compatibility

If you configure an external identity provider, be aware of the following compatibility limitations:

  • Auth0: Supported when the Resource Parameter Compatibility Profile is enabled
  • Microsoft entra ID: Currently unsupported for MCP OAuth because it does not support the resource parameter in authorization requests.
  • Google identity: Currently unsupported as an external IdP for MCP OAuth because Google Identity may reject the MCP server's requested scopes, resulting in an `invalid_scope` error.

    Tip

    If your organization uses Google for SSO, select Celigo as the identity provider. Celigo authentication supports Google SSO and automatically routes users through your Google Workspace sign-in.

Configure API token

  1. In the Access tab, If you don’t have any existing tokens click Create token.

    API tokens_access_mcp.png

    If you have previously created a token, click + Create token in the upper right side of the page.

    Important

    If you have created API tokens under the previous Access tokens tab, they continue to work and appear in the following:Home page > AI studio > MCP Servers > [server] > Access tab > API tokenHome page > Resources > API tokens.

    • Home page → AI studio → MCP Servers → [server] → Access tab → API token
    • Home page → Resources → API tokens
  2. In the General section, enter the required details.

    1. Name your API token, for example, Get a token.
    2. Describe your API token (optional).
    3. Select the required time to auto purge a token: Never, 1 hour, 4 hours, 1 day, 4 days, 10 days, or 30 days.
  3. Click Save.

Manage an API token

Maintaining an API token after it's been created is very straightforward. The Access section lists all the API tokens you've created, including:

  • Name: Displays the name you gave your API token
  • Status: Displays current API token status (Active or inactive)
  • Auto purge: Displays time selected for the API token to auto purge
  • Last updated: Displays the last updated date and time
  • Token: Displays the token to copy, click Show token and select the copy button
  • Actions: You can perform the following action for each token:

    API_token_actions_menu.png
    • Edit token
    • Revoke API token
    • Generate new token

    Capability sets

    Learn more about Capability sets.

Governance

The Governance section of the Access tab controls how much traffic the server accepts and where it can come from: Network policies, Server rate limit, User rate limit, and Usage quota.

Under Network policies, you can restrict which IP addresses can send requests to this MCP server, regardless of the authentication method used. A request must pass both authentication and the server's network policy. If no network policy is assigned, the server accepts requests from any IP address. For steps, see Assign a network policy; for how allow and deny lists work, see Network policies overview.

If your account also restricts end-user authentication with a network policy, an end user must pass both that account-level policy and this server's policy.

A blocked request receives a generic access-denied response and is recorded in this server's request log with the denial reason "IP address not permitted by network policy."

Related articles