Bedrock Agent Core AtlassianOAuth2 credential provider conflicts with Atlassian

This is a real interoperability gap: Bedrock Agent Core is issuing per-request dynamic redirect_uri values while Atlassian requires an exact, pre-registered callback URL. The good news is that there are several pragmatic, secure workarounds you can implement right away. Below I outline the options, trade offs, practical steps, and security considerations so you can pick the right approach for your environment. I also list implementation notes you can hand to an engineer or use as the basis for a paid engagement if you want me to build it for you.

Short summary of options

Configure Bedrock Agent Core to use a fixed redirect URI if the agent supports an override.

Register multiple callback URLs in Atlassian if your deployment can enumerate them ahead of time.

Use a small fixed proxy or relay endpoint that is registered in Atlassian and forwards the request to the dynamic Bedrock callback.

Implement a centralized auth broker that performs the OAuth dance server side and returns tokens to the agent.

As a last resort, raise a feature request with the Bedrock Agent project to support a static redirect_uri option or configurable callback pattern.

Recommended approach for most production use cases Use option 3 or 4, depending on your operational model. A small, secure auth relay or broker gives you the most control, works with Atlassian restrictions, and avoids changing every client instance.

Design A. Simple Relay / Redirector (fastest to implement) Overview

Create a single static HTTPS endpoint and register it as the redirect URL in the Atlassian app configuration.

When Atlassian returns the authorization code to that static endpoint, the relay inspects the request, maps the code back to the originating agent instance (by a short state token), then forwards the code to the Bedrock Agent callback or exchanges the code itself and returns the token to the agent.

How it works in practice

Agent initiates auth. Instead of sending a Bedrock-generated dynamic redirect, it registers a state token and callback hint with the relay. The relay returns a state value.

Agent redirects user to Atlassian including the relay-registered redirect_uri and the state.

Atlassian returns to the relay. The relay looks up the state, maps to the agent instance, then either: a) POSTs the code to the agent callback endpoint, or b) performs the token exchange with Atlassian and POSTs the resulting token to the agent. Option b is preferable for security.

Implementation choices

AWS API Gateway + Lambda is ideal for a minimal managed relay. Add a tiny DynamoDB table mapping state -> agent callback, with TTL.

Alternatively run a small container behind an ALB or CloudFront if you need sticky IPs or advanced routing.

Security notes

Always use PKCE for public clients.

Validate state strictly and use one-time state tokens.

Use TLS and HSTS.

Store client secret and final tokens in a secrets store like AWS Secrets Manager.

Limit the lifetime of forwarding tokens and provide revoke endpoints.

AWS-centric example components

API Gateway for public HTTPS endpoint.

Lambda for auth logic and token exchange.

DynamoDB for state mapping and short TTL.

Secrets Manager for Atlassian client secret storage. AWS docs for reference:

API Gateway and Lambda: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-getting-started-with-rest-apis.html

Secrets Manager: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html

DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html

Design B. Centralized Auth Broker (preferred for enterprise) Overview

The broker performs the entire Authorization Code or 3LO flow, exchanges codes for tokens, stores or issues session tokens to agents, and enforces policy, MFA, logging and token rotation. Agents never hold client secrets. This is cleaner operationally and avoids pushing token logic into many agent instances.

How it works in practice

Agent or user request triggers a broker initiated redirect to Atlassian, including broker state.

Atlassian returns to the broker. Broker exchanges the code for tokens.

Broker stores the tokens securely and returns an ephemeral token or session to the agent. The agent uses the ephemeral token for subsequent calls.

When the agent needs to call Atlassian APIs, it either proxies through the broker or uses the broker to mint short lived credentials.

Why choose this

Centralized security, auditing, token refresh, and easier revocation.

Works well if agents are ephemeral or if you want to enforce uniform policies across tenants.

Trade offs to consider

Extra infrastructure and operational overhead.

Slightly longer initial implementation time than a simple relay.

Other important practical notes

Atlassian app registration: verify whether you can register multiple redirect URIs. If you can, registering a finite set of allowed redirect URIs can be a simple shortcut. See Atlassian developer docs.

If Bedrock Agent Core supports an override or plug-in for the OAuth redirect behavior, prefer a configuration-based fix. Check agent docs or the agent config for a callback override.

Avoid hacks that attempt to spoof redirect_uri by making Atlassian accept dynamic suffixes. Atlassian enforces exact matches for security reasons. Do not attempt to circumvent it with unsafe wildcard techniques.

Operational checklist to ship a relay/broker quickly

Register a static callback URI with Atlassian pointing at your relay.

Implement the relay Lambda with routes: /startAuth, /callback.

/startAuth creates a one-time state and stores mapping state -> agentId or callback hint in DynamoDB. It then redirects user to the Atlassian authorize endpoint with redirect_uri set to the registered relay callback, including state and PKCE.

/callback verifies state, exchanges the code for tokens, and either returns the token to the agent or posts the token to the agent callback.

Log every authorization event securely and set alerting on failures and unusually high rates.

Rotate client secret with Secrets Manager and test secret rotation flow.

Security checklist

Enforce PKCE for public clients.

Use short TTLs for state and session tokens.

Use mutual TLS or signed JWTs for agent-to-broker registration if available.

Audit logs for every exchange and revoke tokens on suspicious activity.

Use strong CSRF protections and validate the redirect state strictly.

Next steps : provide a small reference repo implementing the relay in Node or Python using API Gateway + Lambda + DynamoDB + Secrets Manager, or

design the broker flow with a threat model and CI/CD pipeline, or

review Bedrock Agent Core documentation or configuration to find a built-in override for redirect_uri.

If you want the repo or an implementation plan, tell me your preferred language and whether you want a relay that posts back to agents or one that exchanges tokens centrally and proxies API calls. I can prepare a pull request-ready sample

Relevant documentation

Atlassian OAuth 2.0 documentation: https://developer.atlassian.com/cloud/oauth-2-3lo/

AWS API Gateway and Lambda: https://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-with-rest-apis.html

AWS Secrets Manager: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html

AWS DynamoDB: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html

Share the exact Bedrock Agent Core version and the redirect pattern it emits & I will give you a concrete code sketch for the relay callback handler and the minimal DynamoDB schema to support it.