[alukach]

Part of #588. The CLI half is source-cooperative/source-coop-cli#23.

The API now takes an Ory access token as a bearer, alongside the assertions the data proxy signs, so the CLI can call /api/v1 as the person who logged in. getApiSession routes a bearer by its unverified iss: Ory's tokens go to the new authenticateWithOryAccessToken, and the proxy's go to the existing verifier. Neither falls back to the other or to the session cookie.

The Ory verifier checks the token against Ory's published JWKS, with the issuer (with or without a trailing slash), RS256, expiry, a 30-second tolerance, and the request's origin as audience. An ID token, which Ory issues to the client ID, never passes, and which clients may mint a token for the API is decided in Ory by the audiences each client is allowed. The subject is looked up only as a person's Ory identity. Both verifiers build the session in one place, sessionForAccount. The issuer is NEXT_PUBLIC_ORY_SDK_URL, which is each Ory project's issuer domain.

Deploying:

The CLI's Ory clients need the jwt access-token strategy and this site's origin as an allowed audience. Until a client has both, the API answers that environment's Ory tokens with 401. Nothing else breaks: only newer CLI builds send Ory tokens, so merging first is safe.

	Staging client (a79c9537…)	Production client (197e20e7…)
Allowed audience	https://staging.source.coop ✅	https://source.coop ✅
access_token_strategy: jwt	✅ set 2026-10-13	✅ set 2026-10-13

Changing a client (done for both; kept for reference and rollback): ory patch oauth2-client doesn't exist, and ory update oauth2-client replaces the whole client. So export the client, change one field, and send the whole thing back:

P=d567800d-b705-49d1-8a28-6f92f3a4c053 C=197e20e7-d52d-4d1d-9e54-4b73a342034b
ory get oauth2-client $C --project $P --format json > prod-cli-client.before.json
jq '.access_token_strategy = "jwt"' prod-cli-client.before.json > prod-cli-client.jwt.json
ory update oauth2-client $C --project $P --file prod-cli-client.jwt.json
ory get oauth2-client $C --project $P --format json | jq .access_token_strategy   # "jwt"

Rollback: ory update oauth2-client $C --project $P --file prod-cli-client.before.json.

• No Vercel changes. Each deployment's NEXT_PUBLIC_ORY_SDK_URL is already the issuer in its tokens: https://auth.staging.source.coop on staging and previews (checked against a real staging token), https://auth.source.coop on production. A local API can't accept CLI tokens at all, since no CLI client allows a localhost audience.
• Merging deploys staging. Check with a staging CLI build: source-coop login, then source-coop api whoami --api-url https://staging.source.coop should return your account, and creds with aws s3 ls should still work.
• The next release deploys production. Repeat the checks against https://source.coop. The release ships everything on main: if feat(api): product list, create, view, edit and delete #651 is in it, data.source.coop#253 must be deployed first.
• Rollback is a revert: only Ory-token calls are affected.

Docs:

• ADR-005: amended in docs(adr): amend ADR-005 — the API also accepts Ory access tokens data.source.coop#254. It said the API authenticates proxy-signed tokens; it now records the second signer.
• OpenAPI: the bearerAuth description names source-coop login and source-coop auth token.
• public/llms.txt: checked. Its line ("a token from the CLI's login or a service account") still holds.
• docs.source.coop: checked. No page describes calling the API with a token yet.

Testing

• npm run type-check passes.
• npx jest src/app/api src/lib: 535 passed across 53 suites, including new suites for the Ory verifier and for getApiSession's routing.
• next lint on the changed files reports nothing.
• Against real Ory (staging, 2026-10-13): after the CLI client was switched to jwt, a source-coop login token was an RS256 JWT with iss https://auth.staging.source.coop and aud ["https://staging.source.coop"], and empty ext. That matches what the verifier checks. The API call itself (source-coop api whoami against staging) waits for this to deploy, since a preview's origin isn't an allowed audience.

Related

• CLI login session, which sends these tokens: feat: share one Ory login session between S3 credentials and the source.coop API source-coop-cli#23
• CLI product commands: feat: add product commands and a gh-style api command source-coop-cli#24
• ADR-005 amendment: docs(adr): amend ADR-005 — the API also accepts Ory access tokens data.source.coop#254
• Deployment runbook: in feat: share one Ory login session between S3 credentials and the source.coop API source-coop-cli#23

🤖 Generated with Claude Code

https://claude.ai/code/session_017poyHYEyxWEJct9X8Q71qF

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
source-coop-ui	Ready	Preview	Oct 13, 2026 8:30pm UTC
source-cooperative	Ready	Preview	Oct 13, 2026 8:30pm UTC

[claude]

Claude finished @alukach's task in 24s —— View job

---

✅ No blocking issues — safe to merge.

I read the verifier, the routing in getApiSession and the shared sessionForAccount, and found nothing that blocks.

• Verification: jwtVerify pins RS256, the issuer, the audience (the request origin) and expiry. An ID token's audience is the client ID, so it can't pass.
• Routing: the unverified iss is used only to choose a verifier. A token whose iss isn't Ory's goes to the proxy verifier, which still refuses non-read methods. An Ory-issued token that fails verification returns null and never reaches the proxy verifier or the cookie.
• Subject lookup: fetchByOryId means a service account can't be reached through an Ory token. Disabled accounts are rejected in sessionForAccount.

Non-blocking notes:

• Revocation: a jwt-strategy access token can't be revoked before it expires. That is inherent to the design. The token lifetime configured on the Ory client is the exposure window, so keep it short.
• Errors: if the JWKS fetch fails (a network error rather than a bad token), jwtVerify throws and the call is logged as a verification failure. The caller gets a 401, which is acceptable.

Simplify (ponytail)

• src/lib/api/ory-access-token.ts:35: _setOryJwks and the module-level jwks cache duplicate the pattern in oidc.ts. Share one small cachedJwks(url) helper if a third verifier ever appears. Leave it for now.
• src/lib/api/ory-access-token.ts:38: oryIssuers() returns two strings, and oryIssuers()[0] is used to build the JWKS URL. Fine as is. Keep it.

Docs

The description covers all three: the ADR-005 amendment is linked (data.source.coop#254), the llms.txt line was checked and still holds, and no docs.source.coop page describes calling the API with a token. Nothing is missing.
· branch feat/api-ory-access-tokens

---

💰 Estimated review cost: $0.11 · 0m23s · 4 turns