feat(sts): let platform IdP tokens act as accounts that trust them

[alukach]

Important

• On main, now that feat(sts): exchange opaque API keys at /.sts by hash lookup #235 and feat(sts): serve the FullAccess and ReadOnly roles #236 are merged; four commits. Before they merged, the integration tests that need CI's GitHub token ran on do-not-merge PRs from this branch into main, ci: run the full CI for the #235 → #236 → #237 stack (do not merge) #239 and then ci: run the full CI for the rebased #235 → #236 → #237 stack (do not merge) #240, both closed; they now run on this PR directly.
• Blocked externally for aws-actions/configure-aws-credentials. That action, which source.coop's settings page hands out, checks the credentials it exports with GetCallerIdentity. The proxy cannot answer that call until feat(sts): GetCallerIdentity + real configure-aws-credentials integration test developmentseed/multistore#126 lands, so the action fails after a successful exchange. An AWS SDK's own web-identity provider works now, as does any direct AssumeRoleWithWebIdentity call.
• No multistore bump. multistore 0.7.2 is enough: the one fail-closed check this needs, a required exp, is made here. See "Decisions to flag".

What I'm changing

A token from a platform issuer, GitHub Actions to begin with, can now be exchanged at /.sts. It acts as the service account its RoleArn names, arn:aws:iam::<owner>--<name>:role/FullAccess, and only if that account trusts the token's issuer and subject (ADR-014). The path runs ahead of the STS route, next to the API-key exchange:

1. Route by issuer. The token's iss is read unverified. If it is in PLATFORM_ISSUERS, this path takes the token; otherwise the STS route does, unchanged.
2. Check the request locally. The Role must be one the proxy serves (feat(sts): serve the FullAccess and ReadOnly roles #236), and RoleArn must name an account. That account must be a service account, {owner}--{name} as source.coop's SERVICE_ACCOUNT_ID_REGEX defines it (82 characters at most). Any other account is refused as an untrusting one is, before the token is verified or anything is signed as it.
3. Verify the token against the issuer's JWKS: signature, issuer, that issuer's own audiences, nbf, and a required exp.
4. Rate-limit. STS_EXCHANGE_LIMIT, 100 a minute per client address, is feat(sts): exchange opaque API keys at /.sts by hash lookup #235's API-key limit renamed. It now covers every exchange that may cost a Source API call.
5. Ask the account. POST {SOURCE_API_URL}/api/v1/accounts/{account}/trusts/exchanges with the verified {issuer, subject}, authenticated as the account, which is the contract on source.coop main (feat(accounts): trust subjects per account, the way a role's trust policy does source.coop#566). Per account, issuer and subject, a yes is cached for 60 seconds and a no for 10.
6. Mint under the named Role, with the account as the principal, never the token's subject. Every refusal of the trust reads AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity (request id …), and the proxy logs the account, issuer and subject at WARN.

Nothing unverified reaches the Source API: a token that fails steps 2 or 3 costs no lookup.

Configuration (#223). PLATFORM_ISSUERS is a JSON object from issuer to the audiences its tokens must carry. The audiences are per issuer, so one issuer's audience never admits another's token (ADR-009). An issuer with no audience is refused, and a value that doesn't parse trusts none. AUTH_ISSUER and AUTH_AUDIENCE are unchanged: they configure the person issuer, whose tokens still act as their own subject and ignore RoleArn's account.

Config	Person issuer	Platform issuers
production (wrangler.toml)	Ory, as before	GitHub, audience https://data.source.coop
staging ([env.staging])	staging Ory, as before	GitHub, audience https://data.staging.source.coop
previews (wrangler.preview.toml)	staging Ory, as before	GitHub, audience https://data.staging.source.coop
CI (ci.yml's .dev.vars)	https://auth.example.invalid, which mints nothing	GitHub, audience source-data-proxy-ci

GitHub's audience is the proxy's origin because source.coop's workflow snippet mints the token with audience: <proxy origin>. A preview's hostname changes per PR, so previews accept staging's origin, as they already accept staging's Ory clients.

Why one PR for #222 and #223. The trust check (#222) is reachable only once a second issuer is configured (#223). The configuration is safe only with the trust check: without it, a GitHub token would act as its own subject under an unlimited Role, the risk ADR-009's important note describes. Neither is useful or safe alone.

#222's issue body is superseded by its later comment, the source-cooperative/source.coop#566 contract. The body asked for an issuer-qualified principal. Under the comment's contract, a platform token's subject never becomes a principal at all: the principal is the account that trusts it. The trust answer is cached per issuer, so two issuers' identical subjects cannot share an entry, which is what #222's "done when" asks.

Decisions to flag

• Only a service account can be named. The minted principal is the account segment as given, and source.coop resolves a principal as an Ory identity first. An Ory UUID fits the person and organisation handle grammar, so if a trust ever existed on such an account, platform credentials would act as a person. source.coop writes trusts only to service accounts today, so this is defense in depth, and it matches ADR-014. The 000000000000 placeholder from _default's ARN is refused here too.
• A yes is cached for 60 seconds, a no for 10. cached_fetch caches 200s only, and the route says no with a 403, or a 401 for an account it can't resolve. That refusal is stored next to the positive entry, under its own key, through a cache_put extracted from cached_fetch. So replaying one token from many addresses costs about one lookup per 10 seconds per account, issuer and subject, and a trust just added works within 10 seconds.
• The body is read as well as the status. A 200 whose body says trusted: false is refused and mints nothing. It would also be cached like any 200, as the keys route's refusals are, so it fails closed if the route ever moved to an always-200 contract like the keys route.
• A 404 from the trusts route is a 500, not a refusal. The route answers for any account (401 when it doesn't exist), so a 404 means the API doesn't serve the route at all. That is a deployment mismatch, the same for every account, so it reveals nothing about any one account.
• 401 and 403 read the same to the caller. source.coop answers 401 for an account that doesn't exist, and also when it can't authenticate the proxy. Both are refused like "not trusted" and cached for 10 seconds. The WARN line has the account, issuer and subject, and source.coop's log says which case it was.
• The proxy vouches for the account before it is established. To ask the question, it signs its usual on-behalf-of assertion as the account the caller names, and sends it only to that account's trusts route. This is ADR-014's design. ADR-005 describes such assertions only for callers the proxy has already authenticated (see Docs and ADRs).
• exp is required here, and multistore is not bumped. multistore 0.7.2's verify_token checks exp only when present, the exposure ADR-004's warning says must be closed before other issuers are admitted. Upstream closes it in feat(sts)!: fail closed on empty trust fields, check token type, require exp, log successes developmentseed/multistore#146, released as 1.0.0 by chore(main): release 1.0.0 developmentseed/multistore#153, not yet merged. This path needs only that one check (platform::subject). Bumping would also bring multistore main's BucketConfig::backend_type enum (refactor(core): make BucketConfig::backend_type a typed BackendType enum developmentseed/multistore#155) into the registry for nothing this PR needs. The person path keeps 0.7.2's behaviour, which is harmless while Ory always sets exp. Drop the check when the bump happens.
• One rate limit, renamed. Anyone can mint a GitHub token for this audience in their own workflow, so a replayed or looping token is bounded like a flood of junk keys. feat(sts): exchange opaque API keys at /.sts by hash lookup #235's KEY_EXCHANGE_LIMIT becomes STS_EXCHANGE_LIMIT, one budget of 100 a minute per client address shared by both kinds of exchange; a job exchanges once. It applies after the local checks and verification, and before the trusts lookup. The throttling message now reads "too many exchanges from this address" for both kinds. The namespace ids are unchanged.
• CI's GitHub token now takes the platform path, as it will in production. The credentialed write tests name the account the stub says trusts this repository. In exchange, the person path loses its real-token coverage in CI, since no Ory token exists there. That path is multistore's STS route plus feat(sts): serve the FullAccess and ReadOnly roles #236's Role lookup, and neither changes here.
• Refusal messages avoid angle brackets. multistore's STS error body carries the message unescaped. The first local run caught my arn:aws:iam::<account>:role/<role> breaking the XML.

How I did it

• src/platform.rs (new, wasm-free): parse_issuers, unverified (the header and claims, for routing and the key id), verify (multistore-sts's find_key and verify_token), and subject (requires exp and a non-empty sub).
• src/sts.rs: account(role_arn), the ARN's account segment, and is_service_account_id, source.coop's grammar without a regex crate.
• src/source_api/cache.rs: get_or_fetch_trust, through cached_fetch as the account, with the 10-second refusal entry, and cache_put, extracted from cached_fetch.
• src/lib.rs: platform_exchange and exchange_platform_token, which returns the refusal response itself. with_request_id and throttled are shared with the key exchange, and STS_EXCHANGE_LIMIT replaces KEY_EXCHANGE_LIMIT.
• src/config.rs: PLATFORM_ISSUERS. Cargo.toml: base64, already in the lockfile through multistore-sts.
• wrangler.toml (production and staging) and wrangler.preview.toml: PLATFORM_ISSUERS, and the rate-limit binding renamed. The binding keeps the [[ratelimits]] form ci: deploy with wrangler 4 and declare the rate limit as [[ratelimits]] #245 moved it to for wrangler 4, with the same namespace ids. README.md: the variable, the binding, and a "Platform identity providers" section with the GetCallerIdentity caveat.
• .github/workflows/ci.yml: .dev.vars as in the table above. .github/workflows/staging.yml: the dormant federation smoke test now also needs FEDERATION_TEST_TRUST_ACCOUNT, the staging service account its token acts as. tests/test_writes.py reads it as CI_TRUST_ACCOUNT, falling back to the stub's account.
• tests/stub_api.py: the trusts route. It says yes only for this repository's GitHub subjects on ci-tests--github-ci, and refuses an assertion made as anyone but the account. It also keeps a per-account lookup counter and records who each product was looked up as.

How to test it

• cargo test: all suites pass. The new tests/platform.rs covers audiences kept per issuer, an issuer without an audience dropped, unparseable config trusting none, a JWT read unverified, non-JWTs (an API key among them) not read, and a verified token's subject, with a missing exp, a missing sub and an empty sub each refused. tests/sts.rs covers the account segment, and no account for a bare name, an empty account or a truncated ARN. It also covers the service-account grammar: ids accepted up to 82 characters, and refused for handles, an Ory UUID, the placeholder, uppercase, underscores, one-character halves, a triple hyphen, a second separator, edge hyphens and 83 characters.

• cargo fmt --check, cargo clippy --target wasm32-unknown-unknown -- -D warnings and cargo check --target wasm32-unknown-unknown, through the pre-commit hook.

• pytest tests/ --ignore=tests/test_contract.py against wrangler dev (wrangler 3.114) and the stub, with CI's new .dev.vars: 40 passed, 18 skipped. These ran without a real token:

  • A GitHub-issuer token whose RoleArn names no account is refused with InvalidParameterValue.
  • A person handle, an Ory UUID or the placeholder named as the account is refused with the untrusted AccessDenied, even for a forged token, and no trusts lookup reaches the stub.
  • A forged GitHub token naming a service account is refused as InvalidIdentityToken, with no trusts lookup: the worker fetched GitHub's real JWKS and found no such key.

• With a real GitHub token, on ci: run the full CI for the #235 → #236 → #237 stack (do not merge) #239 (CI's integration job at ba94fbc): 54 passed, 4 skipped. That includes the three tests that need the token, and test_writes.py's credentialed tier, which now goes through this path.

  • A trusted workflow's credentials act as the account: the stub records the account, not the GitHub subject, as the product lookup's subject.
  • An account that doesn't trust the workflow refuses it with the request id, and a replay within 10 seconds costs no second lookup.
  • A yes is cached.

• End to end, after deploy, against staging or this PR's preview, both of which accept staging's audience: give a staging service account a trust for a workflow's subject in source.coop, then run in that workflow:

  permissions: { id-token: write }
  steps:
    - run: |
        curl -sSf -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
          "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://data.staging.source.coop" | jq -r .value > "$RUNNER_TEMP/token"
    - env:
        AWS_WEB_IDENTITY_TOKEN_FILE: ${{ runner.temp }}/token
        AWS_ROLE_ARN: arn:aws:iam::<service-account-id>:role/FullAccess
        AWS_ENDPOINT_URL_STS: https://<proxy>/.sts
        AWS_ENDPOINT_URL_S3: https://<proxy>
        AWS_REGION: us-west-2
      run: aws s3 ls s3://<owner>/<product>/

  Then remove the trust, and within a minute the next exchange reads AccessDenied … (request id …).

Docs and ADRs

• ADR-009 (platform IdPs): its decision holds (platform issuers, per-issuer audiences, fail closed per issuer), and this implements it. Its migration step 3 and its important note are superseded by ADR-014: platform issuers are not added to _default, and a platform token acts only as an account that trusts it. A note there now says so, and its status says implemented in part. ADR-014 (docs(adr): ADR-014 service accounts; amend ADR-010 and ADR-013 #232) does not list ADR-009 under Amends; docs(adr): ADR-014 service accounts; amend ADR-010 and ADR-013 #232 may want to.
• ADR-004 trusted "exactly one OIDC issuer" and warned that exp must be enforced before other issuers are admitted. A note under its trust model now points to platform issuers and ADR-014. Its exp warning now says platform tokens must carry exp and that the proxy checks it.
• ADR-001 said source_identity is "the original OIDC sub — the caller's Ory identity". It now says it is the account an API key or a trusted platform token names, which also covers feat(sts): exchange opaque API keys at /.sts by hash lookup #235's keys.
• ADR-005 says the proxy signs lookups as a caller it has authenticated. The trusts lookup is signed as the account a caller names, before that account is established, and only for that one route. ADR-014 (docs(adr): ADR-014 service accounts; amend ADR-010 and ADR-013 #232) records this; ADR-005's text does not, so it is for docs(adr): ADR-014 service accounts; amend ADR-010 and ADR-013 #232 or docs(adr): revise ADR-013 — API keys are opaque secrets resolved by the platform #234 to amend.
• ADR-014 (docs(adr): ADR-014 service accounts; amend ADR-010 and ADR-013 #232), "the token path is then…", is what this implements, and it still holds.
• docs.source.coop: no page on main covers GitHub Actions against the proxy. The unattended-workflow guide, Unattended workflow guide docs.source.coop#34, should give the token-file workflow above and the configure-aws-credentials caveat until feat(sts): GetCallerIdentity + real configure-aws-credentials integration test developmentseed/multistore#126.
• source.coop: src/lib/services/github-workflow.ts on main hands out configure-aws-credentials with audience: <proxy origin> and role/FullAccess. The audience matches PLATFORM_ISSUERS in production and staging, and the Role resolves since feat(sts): serve the FullAccess and ReadOnly roles #236. The action itself waits on feat(sts): GetCallerIdentity + real configure-aws-credentials integration test developmentseed/multistore#126.

PR Checklist

• This PR has no breaking changes. Person-issuer tokens and API keys behave as before; GitHub tokens, refused until now as an untrusted issuer, take the new path.
• I have updated or added new tests to cover the changes in this PR.
• This PR affects the Source Cooperative Frontend & API: it calls the trusts route from feat(accounts): trust subjects per account, the way a role's trust policy does source.coop#566, already on main.

Related Issues

Closes #222. Part of #223: this is the proxy side, and #223's "done when", a workflow in an unrelated repository writing with only its ambient token, also needs a deployment and, for the action source.coop hands out, developmentseed/multistore#126. Builds on #235 and #236, both merged. ADRs: #232 (ADR-014). Upstream: developmentseed/multistore#126, developmentseed/multistore#146, developmentseed/multistore#153. Epic: source-cooperative/source.coop#491.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R1eiTse4416N6uTgAy4Ddd

[claude]

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

---

✅ No blocking issues — safe to merge.

I read the Rust changes (src/platform.rs, src/lib.rs, src/source_api/cache.rs, src/sts.rs). I did not run the tests or read the Python tests, workflows or docs.

• Ordering: the local checks (Role, account segment, service-account grammar) run before JWKS verification. Verification runs before the rate limit, and the rate limit before the trusts lookup. No unverified token reaches the Source API.
• Principal: minted credentials use the account, never the token's sub. The service-account grammar keeps an Ory UUID or a handle from becoming the principal.
• exp: platform::subject requires exp and a non-empty sub, which closes the gap in multistore 0.7.2.
• Audiences: they are per issuer, and a bad PLATFORM_ISSUERS value fails closed.
• Cache keys: PATH_SEGMENT percent-encodes everything but -._~, so & and = in a subject can't forge a colliding key. The &refused entry can't collide either.
• Trust answers: a 200 with trusted: false is refused and its cached entry deleted. Other errors, including a 404, are not cached as refusals.

Non-blocking notes

• src/source_api/cache.rs:~240: the refused-key lookup and the positive lookup are separate cache reads, so a no costs two edge reads on the first miss. That's fine at this scale.
• src/lib.rs: the rate limit runs after JWKS verification. A flood of forged tokens therefore costs a JWKS fetch each, though only the first fetch per issuer hits GitHub if jwks_cache() is shared across requests. Worth confirming that cache lives long enough in the worker.

Simplify (ponytail)

• src/lib.rs PlatformToken: a struct used by one caller and destructured immediately. Pass sts, header, issuer and audiences as arguments, or drop header by reading kid in platform_exchange.
• src/sts.rs account: collect::<Vec<_>>() for a six-way split. role_arn.splitn(6, ':').nth(4).filter(|a| !a.is_empty()) replaces it. It would also need the arn prefix and field-count checks the current pattern gives, so keep the current form if you want those enforced.
• src/platform.rs parse_issuers: the logging filter could be a plain retain. The error log is worth keeping, so this is a wash.

---

💰 Estimated review cost: $0.22 · 0m24s · 9 turns

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-237.source-coop.workers.dev

• Date: 2026-10-01T04:17:59Z
• Commit: 784c3de

[alukach]

Rebased onto main after #235, #236 and #245 merged, and force-pushed: the branch is now this PR's four commits. One conflict, in wrangler.toml, wrangler.preview.toml and README.md: #245 moved the rate-limit binding from [[unsafe.bindings]] to wrangler 4's [[ratelimits]], while this PR renames it KEY_EXCHANGE_LIMIT → STS_EXCHANGE_LIMIT. Resolved as [[ratelimits]] with the new name and the same namespace ids; nothing references the old name. cargo test passes locally and all CI passes on the new head, including the preview deploy and integration tests. Description updated.