How to validate a self-issued JWT? - oauth-2.0

Question

I was looking at the section about Self-issued OpenID Provider Response, where they describe a method of validation, where the public key is included in the token itself. They use this as an example token:
{
"iss": "https://self-issued.me",
"sub": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
"aud": "https://client.example.org/cb",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"sub_jwk": {
"kty":"RSA",
"n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
"e":"AQAB"
}
}
I get how you can use the appended key for validation. But I don't get what prevents someone from using a fake key-pair to create a similar token. The only way I see this happening is if the public key is known by the validator from somewhere else, but in that case it doesn't make a lot of sense to include it in the token.
How does this work?

Answer 1

The way this work is that the hackers don't have access to the private key that was used to sign the token signature. The public key is derived from the private key.
The public key is safe to distribute as it only verifies the token signature. T
I don't think it's that common to include the public key inside the token as the token size gets bigger. Instead, you, as a receiver, download it separately, or it is provided to you some other way.
The picture below gives a summary of how public-key cryptography works.

Answer 2

But I don't get what prevents someone from using a fake key-pair to create a similar token.
Given the validations in Self-Issued ID Token Validation there is no feasible way for "someone" to sign a token which would have the same sub (JWT Subject). Of course they may sign a Token which would pass validations, but ONLY for a different subject. So IF you choose to accept Self-Issued ID Tokens, the guarantee you get is that you can re-identify the same Subject. That's kind of the whole point, Self-Issued OpenID providers are personal wallets, given the cryptography present in the flow you can be sure a given returned subject is the same one you encountered prior as long as sub is the same as before (or one that you know and have established trust with OOB).
Node.js code as a reference:
import * as assert from "node:assert";
import * as jose from "jose";
let jwt;
const redirect_uri = "https://rp.example.com/siop/cb";
const nonce = "n-0S6_WzA2Mj";
{
// this is unreachable by the party verifying
const kp = await jose.generateKeyPair("ES256");
const sub_jwk = await jose.exportJWK(kp.publicKey);
jwt = await new jose.SignJWT({ sub_jwk, nonce })
.setSubject(await jose.calculateJwkThumbprint(sub_jwk))
.setIssuer("https://self-issued.me")
.setAudience(redirect_uri)
.setProtectedHeader({ alg: "ES256" })
.setExpirationTime("5m")
.setIssuedAt()
.sign(kp.privateKey);
}
const verified = await jose.jwtVerify(
jwt,
async (protectedHeader, token) => {
const { sub_jwk, sub } = JSON.parse(
new TextDecoder().decode(jose.base64url.decode(token.payload))
);
assert.equal(sub === (await jose.calculateJwkThumbprint(sub_jwk)), true);
const key = await jose.importJWK(sub_jwk, protectedHeader.alg);
assert.equal(key.type, "public");
return key;
},
{
audience: redirect_uri,
issuer: "https://self-issued.me",
}
);
assert.equal(verified.payload.nonce, nonce);
console.log(verified);