Skip to content
1Claw Academy
Curriculum/Security Foundations2 minBeginner · Lesson 19 of 19

Lab: read 1Claw's real signing keys

Lab

Fetch 1Claw's live JWKS and OIDC discovery document, with no account and no key of your own, and see the public-key lessons in the actual product.

Everything in this track has been demonstrated with keys you generated. This lab uses none of your own. Every 1Claw JWT, the ones agents exchange for and the ones federation partners validate, is checked against a document anyone can fetch.

  1. 1

    Fetch the OIDC discovery document. It is how a relying party finds everything else without being told out of band.

    code
    curl -s https://api.1claw.co/.well-known/openid-configuration | python3 -m json.tool
  2. 2

    You should see the issuer and, critically, jwks_uri.

    text
    {
    "issuer": "https://api.1claw.co",
    "jwks_uri": "https://api.1claw.co/.well-known/jwks.json",
    "token_endpoint": "https://api.1claw.co/v1/oauth/token",
    ...
    "id_token_signing_alg_values_supported": [
        "EdDSA",
        "RS256"
    ]
}
  3. 3

    Now fetch the keys themselves.

    code
    curl -s https://api.1claw.co/.well-known/jwks.json | python3 -m json.tool
  4. 4

    Two keys, not one, and that is not an accident.

    text
    {
    "keys": [
        {"kty": "OKP", "alg": "EdDSA", "kid": "eddsa-v1", "crv": "Ed25519", "x": "..."},
        {"kty": "RSA", "alg": "RS256", "kid": "rs256-v1", "n": "...", "e": "AQAB"}
    ]
}

Both keys verify signatures and neither one signs anything on your machine. That is the entire property from the public-key lesson, in production: the ability to check is public, the ability to produce is not, and this endpoint is the only thing on the internet that needs to know both keys exist.

  • OKP with crv Ed25519 is the agent-JWT key. It is fast, and it is what every 1claw agent-token exchange signs with.
  • RSA with RS256 is the federation key. External relying parties overwhelmingly expect RSA, which is documented in this course's OIDC federation lesson as the reason two algorithms coexist rather than one.
  • kid is versioned: eddsa-v1, rs256-v1. When 1Claw rotates, the old kid stays in this array until nothing depends on it, which is the same coexistence property the envelope-encryption lab demonstrated with KEK versions.
Watch out

This is a live production endpoint. The exact key material, and eventually the kid version, will change over time. What will not change is the shape: two algorithms, a versioned kid, and an issuer that matches what every 1Claw-issued token's iss claim says.

Tip

You now hold everything a relying party needs to verify a 1Claw-issued token without ever talking to 1Claw's servers at request time: fetch the JWKS once, cache it, and check signatures locally. That is what makes JWT verification cheap at scale.

Check your understanding

3 questions
1

Why does the JWKS publish two keys instead of one?

2

What lets a relying party verify a 1Claw token without calling 1Claw at request time?

3

The kid values are eddsa-v1 and rs256-v1. What does the version number tell you?