Credentials overview
Credentials define the identity that watsonx Orchestrate uses when it connects to third‑party applications. You manage credentials so that tools can authenticate securely and operate with the correct level of access. watsonx Orchestrate supports two credential models team credentials and member credentials to accommodate system‑level access and user‑specific authorization requirements. Both types of credentials are stored securely by the platform and can be added, updated, and deleted from the Credentials tab in the Connections settings or from Profile settings for personal credentials.
Team credentials
Team credentials define a shared identity that all users of an agent use. Team credentials come from a shared service account that is managed by builders or administrators and represent a single identity for accessing the external application. Users are never prompted for team credentials.
In OAuth 2.0 Authorization Code configurations, the builder is redirected to the external application to authorize access on behalf of the shared account. This links the connection to the external system’s service identity and establishes the shared credentials that are required for integration.
Team credentials are suited for scenarios that require shared permissions, user‑independent requests, or service‑level access.
Member credentials
Member credentials represent the individual identity of each user in the external application. These credentials allow actions to run on behalf of the user, enabling external systems to apply user-specific permissions, roles, and access policies. Member credentials originate directly from the user’s own application identity and help verify that the external system applies the correct authorization for that specific user.
Member credentials (Draft): Member credentials are used only during testing. Each user provides personal credentials when the tool runs in preview chat.
Member credentials (Live): The user enters personal credentials when the tool needs access to the external system in the live environment. These credentials are stored securely for future requests.
Member credentials (SSO): SSO replaces manual credential entry. The authenticated identity is passed automatically when the channel supports delegated access.
If you select “Member credentials” and do not provide the details, watsonx Orchestrate prompts you to enter them through the chat interface the first time you use the tool. The credentials are stored securely and available for subsequent tool invocations.
The following table summarizes where team and member credentials originate and how they are collected across Draft and Live interactions.
Credential model | Who provides the credentials | Where credentials are collected | When they are collected |
|---|---|---|---|
Team credentials | Builder or administrator | Credentials field | During connection setup |
Member credentials (Draft) | User | Preview chat | Testing in the draft environment |
Member credentials (Live) | User | In‑portal chat or deployed channels (Slack, Microsoft Teams, embedded chat) | First time the tool runs in live |
Member credentials (SSO) | Identity provider (IdP) | No manual entry (identity flows automatically) | At sign‑in and reused for later requests |
Credential management in watsonx Orchestrate helps maintain the correct identity for each integration whether shared or individual and supports consistent authentication behavior across draft and live environments. By understanding how team and member credentials originate and how they are used at run time, you can design integrations that meet security requirements and each application’s authorization model.
Credentials can be managed from the connections settings. For information about managing credentials from the connections settings, see Managing credentials from connection settings.
Member credentials belong to individual users and can be reviewed, updated, or removed at any time from profile settings. For information about managing member credentials from Profile settings, see Managing credentials from profile settings.
Credential parameters by authentication type
The credential parameters vary depending on the authentication type used.
Authentication Type | Required Parameters |
|---|---|
API Key | API key |
Basic Authentication | username and password |
Bearer Token | Bearer token |
Key-Value Pair | Key and value |
OAuth2 Authorization Code | Server URL, token URL, authorization URL, client ID, client secret |
OAuth2 Client Credentials | Server URL, token URL, authorization URL, client ID, client secret, grant type |
OAuth2 Password | username and password |
For all Single Sign-On (SSO) authentication types, only Member credentials are supported. For the Key Value Pair authentication type, only Team credentials are supported. For all other authentication types, both Member credentials and Team credentials are supported.
Credential support by deployment type
Credential behavior varies depending on where the workflow runs. The following table summarizes the credential support for each deployment type to help you determine which configuration is appropriate for your use case.
Deployment type | Team credentials | Member credentials |
|---|---|---|
Embed chat | Supported for all authentication types | Supported only for Single Sign-On authentication types |
In‑portal or native watsonx Orchestrate chat | Supported for all authentication types | Supported for all authentication types except Single Sign-On and Key Value Pair |
All other channels | Supported for all authentication types | Not supported for any authentication types |