Handling Authentication with Your API
Many APIs require authentication (e.g., API keys, Bearer tokens) to access their resources. AgentB allows you to securely connect your agents to these protected APIs.
Goal: Modify the AgentB server to handle an API that requires a Bearer token, and demonstrate how the AgentB facade can manage request-specific authentication.
Prerequisites
Completed Tutorial 2: Connecting AgentB to Your API.
You have an API endpoint that requires a Bearer token (or you can simulate one). For this tutorial, we'll conceptually use a "secure" version of a service.
The Challenge: Dynamic Authentication
Often, the authentication token (like a user-specific Bearer token) isn't static. It might come from:
A user's session.
An HTTP
Authorizationheader in the request made to your AgentB server.A secure vault or configuration specific to the user making the request.
AgentB's AgentB.getExpressStreamingHttpHandler (and its core logic) supports a powerful authorizeRequest callback that can return PerProviderAuthOverrides. This allows your AgentB server to dynamically provide authentication details for specific tool providers on a per-request basis.
Step 1: Modify Your OpenAPI Specification (Conceptual)
Let's assume you have an OpenAPI specification for a "My Secure Service" that requires a Bearer token.
specs/my-secure-service.json (Conceptual Excerpt):
The key parts are components.securitySchemes defining BearerAuth and the top-level security applying it.
Step 2: Update Your AgentB Server
We'll modify the server.ts from previous tutorials.
Step 3: Test the Authenticated Endpoint
Restart your AgentB server (
node server.jsornpx ts-node server.ts).Use
curlor Postman to interact.
Scenario 1: No Authentication Token
Expected Server Logs (Conceptual):
(The client would receive an HTTP error, likely 403 Forbidden, or whatever your AgentB.getExpressStreamingHttpHandler sends when authorizeRequest returns false).If authorizeRequest returned true instead of false in this case, the flow would continue, and the LLM might try to use the tool. The actual API call by OpenAPIConnector would then fail if the (empty) static token isn't valid for "My Secure Service".
Scenario 2: With a Valid (or placeholder) Authentication Token
Replace YOUR_ACTUAL_OR_PLACEHOLDER_TOKEN with a token.
Expected Server Logs (Conceptual):
Expected Client Output (curl):
You'll see the usual AgentB event stream. If the API call made by the mySecureService_getSecureData tool is successful (because the token was valid for the target API), the agent will receive the data and formulate a response. If the token is invalid for the actual "My Secure Service" API, the tool execution will fail, and the agent will report that.
Key Takeaways
authorizeRequestCallback: This function inAgentB.getExpressStreamingHttpHandler(options)is your central point for request-level authorization and dynamic authentication.PerProviderAuthOverrides: TheauthorizeRequestcallback can return this object. The keys are theids you defined in yourToolProviderSourceConfig(e.g.,'mySecureService'). The values areConnectorAuthenticationobjects ({ type: 'bearer', token: '...' },{ type: 'apiKey', ... }, etc.).Dynamic Token Injection:
OpenAPIConnector(used internally by AgentB for OpenAPI tools) will pick up these dynamic overrides for the specific API call, overriding any static authentication configured for that provider.Security: Your AgentB server acts as a secure gateway. Client applications send requests to your server, which then securely attaches the necessary credentials before the agent's tools call the downstream APIs. Never expose raw user tokens directly to the LLM or store them insecurely.
This pattern is powerful for multi-tenant applications or scenarios where each user request to your AgentB server might need to use different credentials for the underlying tools/APIs.
Next Up: Creating a Custom Tool that doesn't rely on an OpenAPI specification.
Last updated