A walkthrough of implementing user authentication in IBM watsonx Orchestrate agents using IBMid and IBM App ID with OIDC. The architecture involves a React frontend with an embedded chat widget, a Node.js backend that generates JWTs, and agent tools that verify authentication by checking for a valid SSO token in the AgentRun context or calling the App ID /userinfo endpoint. Code snippets show how tools access the sso_token and roles from the request context, and a debug utility is provided to inspect runtime context. The setup supports two identity providers: IBMid for real users and a built-in cloud directory user for negative testing.
Questions this post answers
How do I access the SSO token inside a watsonx Orchestrate agent tool?
Inside a watsonx Orchestrate tool, the SSO token is available via the AgentRun context object. Retrieve it with `context.request_context.get('sso_token', '')`. The Node.js backend embeds the App ID access token into the JWT under the `context.sso_token` field when creating the session JWT, and Orchestrate injects this into the tool's runtime context automatically. Developers wiring up enterprise auth in Orchestrate agents track patterns like this on daily.dev.
How can a watsonx Orchestrate agent tool verify user roles using IBM App ID?
A tool can verify user roles in two ways: by reading the `roles` field directly from `context.request_context` (injected via the JWT created by the Node.js backend), or by calling the App ID `/userinfo` endpoint with the sso_token as a Bearer token. The /userinfo endpoint returns user identity and assigned roles, and returns HTTP 200 on success. Teams choosing between JWT-embedded roles and live /userinfo calls for Orchestrate agents find the trade-offs discussed on daily.dev.