jpm-oauth

JPM OAuth implementation

Generate JWT-signing + access-token-exchange code that follows JPM's IDAnywhere OAuth contract. The generated module caches the access token until just before its server-set expiry, so the merchant's app reuses one token across many API calls instead of regenerating per request.

This skill is typically invoked from the end of jpm-integrations-get-started (its Step 4). When run standalone, it gathers the same inputs interactively.

Step 1 — Verify prerequisites

The merchant must have all four of:

• clientId (e.g. CC-123456-D12992-232222-TEST)
• certificate path (PEM .cer from JPM)
• private key path (PEM key paired with the certificate)
• SHA-1 thumbprint of the cert (40 hex chars; colons optional — code will normalize)

If you arrived from jpm-integrations-get-started, these are already in conversation context — use them.

If invoked standalone:

1. Ask the user where the credentials live: file paths, an .env, or in conversation.
2. If anything is missing, tell the user to run jpm-integrations-get-started first and exit. Do not invent placeholder values.

Step 2 — Environment

Ask:

• Question: "Which JPM environment are you targeting?"
• Header: "Environment"
• Options:
  • "CAT (test)"
  • "PROD"
  • "Both — generate code that switches via env var"

Do not prompt the user for the resource_id. The generated module reads it from the JPM_RESOURCE_ID environment variable at runtime, and the intake skill's .env.example already includes that key with a comment pointing the user at the JPM onboarding email (where the value lives). Just remind the user in your wrap-up to fill JPM_RESOURCE_ID in their .env before running the auth module — and that CAT and PROD have different resource_id values, so the right one must be in the .env for the environment they're targeting.

Step 3 — Education and JWT TTL

Show the user this guidance verbatim before asking the TTL question:

Two TTLs to know about:

• Access token TTL — set by JPM's IDAnywhere server, returned as expires_in (seconds) in every token response. The generated module reads this value and reuses the access token across requests until shortly before it expires. Don't treat it as fixed — server-side defaults can change.

• JWT TTL — client-controlled (you pick). The JWT is the credential you hand to IDAnywhere to get an access token. JPM's guidance: 8 hours for PROD; longer is fine for CAT.

Anti-pattern to avoid: generating a fresh JWT and a fresh access token on every API call (think of it like running a card auth on a brand-new payment instrument every transaction — wasteful and slow). The access token is reusable until expiry. The generated module caches it in memory and only refreshes it when within ~30s of expiry. Call getAccessToken() once per outbound request and let the cache do its job.