Skip to content

feat(identity): keys from a key source, a person without an org acts in their own, a key set given - #301

Merged
rami-hatoum merged 3 commits into
mainfrom
feat/api-keys-come-from-a-key-source
Oct 23, 2026
Merged

rami-hatoum merged 3 commits into
mainfrom
feat/api-keys-come-from-a-key-source

Conversation

@rami-hatoum

Copy link
Copy Markdown
Contributor

What this changes

Three things the identity package decided from configuration alone.

  • API keys come from a key source. The authenticator looked a presented abk_<id>_<secret> key up in the list the operator configured. The lookup is now a port, ApiKeySource, whose one implementation is that configured list; the constant-time check is unchanged, and the configured list alone still decides the access mode, so a server with no keys and no sign-in stays closed. A test revokes a key mid-run through a fake source and sees it refused.
  • A person whose token names no org acts in the org whose id is their subject. Such a token was refused outright. It now acts in that one org and in no other, as personal accounts work at the identity service; a subject that is not an org id other than local is refused in words. The authentication reference, the security guide, the OpenAPI document and the terminology say the rule; the API's tests show the subject's org answering and another org refused.
  • The identity service's key set may be given. The verifier fetched the issuer's key set through its metadata. It now takes a key source: discovery as before, IDENTITY_JWKS_URL for a key set read at a URL and kept ten minutes, or IDENTITY_JWKS for the key set itself; setting both stops the start, and a malformed key set is refused with its place named.

Tests

  • A key the source does not know, a revoked key, a token with no org for its own org and for another, the key set given and at a URL, discovery by default; the two server start tests fail when the key set is not composed.
  • pnpm check passes on each commit.

rami-hatoum and others added 3 commits October 23, 2026 13:42
… configured list today

The authenticator asks an ApiKeySource, keyOf(id), for the entry of the id a presented key names,
on every request, and compares the digests in constant time as before. The list the operator
configured, configuredApiKeys, is the one source, and the server composes it; a source that keeps
its keys elsewhere admits a key it issues and refuses one it revokes while the server runs. The
configured list alone still decides the access mode, and no source is asked in local mode or in a
closed server.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…se id is their subject

A session or an access token that holds neither o nor org_id names no org, as the token of a person
signed in with no organization of their own does, and was refused for a missing o or org_id claim.
It now acts in the org whose id is its sub, and in no other, and the dispatcher's rules hold there
as in any org; a sub that is not an org id other than local is refused, naming the sub claim. A
token that holds the org claim of the other form without its own is refused as before, so the API's
tests of a refused org claim now give the token that claim. The openIdConnect scheme of the OpenAPI
document, the kept document, the security guide and the terminology say the new rule.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…Y_JWKS or at IDENTITY_JWKS_URL

The verifier takes its signing keys from an IssuerKeySource of the identity package: discovery
through the issuer's metadata, the default as before; a URL, read in place of the metadata's
jwks_uri and kept for ten minutes as a key set found through it is; or a key set given, which is
read from nowhere. The server reads IDENTITY_JWKS, the JSON of a key set that holds a key, and
IDENTITY_JWKS_URL, an https URL, beside IDENTITY_ISSUER, refuses both at once, and composes the
source they name, so a server whose issuer publishes its keys another way, or that should read
nothing of the issuer at start, still signs people in.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@rami-hatoum
rami-hatoum merged commit ca6f754 into main Oct 23, 2026
20 checks passed
@rami-hatoum
rami-hatoum deleted the feat/api-keys-come-from-a-key-source branch October 23, 2026 12:53
rami-hatoum pushed a commit that referenced this pull request Oct 23, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.18.0](v0.17.0...v0.18.0)
(2026-10-23)


### Features

* **identity:** keys from a key source, a person without an org acts in
their own, a key set given
([#301](#301))
([ca6f754](ca6f754))
* **server:** the npm package carries every package as a subpath, with
its testing entry
([#304](#304))
([caf2e36](caf2e36))


### Bug Fixes

* **coordination:** the workflow spec SDK compiles a validator on first
use, not when imported
([#308](#308))
([0dcd0df](0dcd0df))
* **workflow-host:** the follower notes each unreadable record, and a
first follow misses nothing
([#302](#302))
([7c5588c](7c5588c))
* **workflow-host:** the waiting measurement names the run of each
record it writes
([#299](#299))
([69ad59f](69ad59f))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: beonautobot[bot] <298957281+beonautobot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant