PR Custody

fix(adobe_document_generation_api): migrate auth to S2S OAuth and correct IMS host

@AgentWrapperchecks n/achecks…fix/PLEN-2215-adobe-doc-gen-s2s → master1 files · +45 −13updated 1mo ago

▸Description· 2 comments · 1 noise

Summary

Per the PLEN-2215 audit (Pattern B "soft misuse"), adobe_document_generation_api_oauth declared mode: 'OAUTH2' but used grant_type: 'client_credentials' — Adobe IMS Server-to-Server is the correct flow for Document Generation.

Two fixes:

Mode: migrate to mode: 'S2S_OAUTH2' (adobe_document_generation_api_s2s_oauth2). client_id/client_secret as auth_config_field (admin-managed Developer Console credentials). auth_method: 'body'.
Token URL: switch from ims-na1.adobeio.com to ims-na1.adobelogin.com — the correct Adobe IMS host per Adobe Server-to-Server docs. The old domain would fail at token exchange.

Preserves the X-API-Key: client_id header injection (Adobe APIs require X-API-Key alongside the bearer token).

Drops unused authorization_url, authorization_params, disable_pkce, token_request_auth_method.

⚠️ Backwards compatibility: existing connections (if any) under adobe_document_generation_api_oauth will need to be re-created. Per the audit + the wrong-domain bug, the prior scheme cannot produce a working token.

Pattern matches PayPal (ComposioHQ/mercury#21885) and Neo4j (ComposioHQ/mercury#23064).

Refs: PLEN-2215.

Test plan

make validate-config file=apps/adobe_document_generation_api/config.ts passes.
Create staging auth config with real Adobe Developer Console credentials; confirm /ims/token/v3 exchange against ims-na1.adobelogin.com returns 200.
Hit https://pdf-services.adobe.io/assets with the resulting bearer token and X-API-Key: <client_id>; confirm 200.

@AgentWrapper1mo ago

Root Cause Analysis

The broken adobe_document_generation_api_oauth scheme replaced by this PR was introduced in:

Origin PR: ComposioHQ/mercury#13790 — "feat(adobe_document_generation_api): add config.ts with OAUTH2 auth"
Author: @rube-by-composio
Approved by: @Karthikeya-Meesala
Merged: 2026-02-16
Commit: c96ddd15

Two bugs shipped in this commit, both fixed by this PR:

Per the PLEN-2215 audit, Pattern B "soft misuse" — mode: 'OAUTH2' declared with grant_type: 'client_credentials'.
Wrong Adobe IMS host — token URL pointed at ims-na1.adobeio.com instead of the correct ims-na1.adobelogin.com per Adobe's Server-to-Server docs. The wrong domain alone would have prevented the scheme from ever working, regardless of mode.

🤖 Auto-generated RCA.

@AgentWrapper1mo ago

original PR, https://github.com/ComposioHQ/mercury/pull/13790

Cortex agent though it's adding s2s oauth2 but it added simple oauth2 (based on reading that PRs description ^)

▸ 1 bot/status comment hidden

@linear-code[bot]1mo ago

Context

Neo4j Aura's public API (https://api.neo4j.io/oauth/token) only supports the OAuth2 client_credentials grant — there is no redirect authorization_code flow. Today the toolkit declares four auth schemes, two of which target this endpoint:

neo4j_oauth (mode: OAUTH2) — uses OAUTH2 mode but with token_params: { grant_type: 'client_credentials' } and authorization_url === token_url, which is a hack around the missing client_credentials support in OAUTH2.
neo4j_s2s_oauth2 (mode: S2S_OAUTH2) — the correct mode, but currently a stub:
- strictFields: {} → no client_id / client_secret fields are exposed at auth-config creation, so users have no way to provide credentials.
- token_config.auth_method is unset.
- token_config.params: {} → no credentials are sent in the token exchange.

Net effect: the S2S scheme is visible in the UI but cannot actually succeed.

Proposed direction

Flesh out neo4j_s2s_oauth2 in mercury/apps/neo4j/config.ts to match the PayPal S2S pattern (see ComposioHQ/mercury#22415):

Add strictFields.db.client_id and strictFields.db.client_secret with field_type: 'auth_config_field'.
Set token_config.auth_method: 'basic' (Neo4j Aura accepts HTTP Basic).
Set token_config.params: { client_id: fields.client_id, client_secret: fields.client_secret }.

Open questions for planning

Do we deprecate or remove neo4j_oauth? It overlaps with the S2S scheme and the redirect flow isn't real.
Any per-tenant/region URLs for Neo4j Aura that would require the same base_url_host eval-field trick used for PayPal / Zoho Mail?

References

PayPal S2S fix (same pattern, recent):

loading diff…

@linear-code[bot]1mo ago

Context

neo4j_oauth (mode: OAUTH2) — uses OAUTH2 mode but with token_params: { grant_type: 'client_credentials' } and authorization_url === token_url, which is a hack around the missing client_credentials support in OAUTH2.
neo4j_s2s_oauth2 (mode: S2S_OAUTH2) — the correct mode, but currently a stub:
- strictFields: {} → no client_id / client_secret fields are exposed at auth-config creation, so users have no way to provide credentials.
- token_config.auth_method is unset.
- token_config.params: {} → no credentials are sent in the token exchange.

Net effect: the S2S scheme is visible in the UI but cannot actually succeed.

Proposed direction

Flesh out neo4j_s2s_oauth2 in mercury/apps/neo4j/config.ts to match the PayPal S2S pattern (see ComposioHQ/mercury#22415):

Add strictFields.db.client_id and strictFields.db.client_secret with field_type: 'auth_config_field'.
Set token_config.auth_method: 'basic' (Neo4j Aura accepts HTTP Basic).
Set token_config.params: { client_id: fields.client_id, client_secret: fields.client_secret }.

Open questions for planning

Do we deprecate or remove neo4j_oauth? It overlaps with the S2S scheme and the redirect flow isn't real.
Any per-tenant/region URLs for Neo4j Aura that would require the same base_url_host eval-field trick used for PayPal / Zoho Mail?

References

PayPal S2S fix (same pattern, recent):