Openid-Connect on Sauvik Biswas

JWKS and RS256: Dropping the Shared JWT Secret

Mon, 22 Jun 2026 00:00:00 +0000

Why verify-only apps shouldn’t hold the signing key #

v07 added OpenID Connect on top of v06’s split architecture. The id_token is a signed JWT. Mode B access tokens are JWTs too. Both used HS256 with a shared JWT_SECRET copied into three .env files.

That worked in a toy lab. It is not how production IdPs ship.

Concern	v07 (HS256 + `JWT_SECRET`)	v08 (RS256 + JWKS)
Who can sign tokens?	Any process with `JWT_SECRET`	Only the auth server (private key)
Who can verify tokens?	Any process with `JWT_SECRET`	Anyone with the public key from `jwks_uri`
Key rotation	Re-sync `JWT_SECRET` everywhere	Publish new key in JWKS; verifiers pick by `kid`
Discovery	`id_token_signing_alg_values_supported: ["HS256"]`	`["RS256"]` + `jwks_uri`
Real IdPs (Google, Okta, Auth0)	Not available (no shared secret)	RS256; public keys at `jwks_uri` in discovery

What HS256 actually means #

HS256 is symmetric: one secret signs and verifies. In v07, the client verified id_token with JWT_SECRET and the resource server verified Mode B access tokens with the same secret while the auth server signed with it.

Intermission: What Industry Ships and Who Gets Paid

Sun, 21 Jun 2026 00:00:00 +0000

A deliberate pause #

v07 is in the repo. It consists of OpenID Connect on top of the v06 split; i.e. id_token, discovery, UserInfo, nonce, and the openid scope; while keeping v06’s opaque-or-JWT access-token modes. The runnable snapshot is versions/v07-openid-connect/. In my opinion, that is a lot of ground for seven incremental snapshots.

I started drafting this market-research post earlier, then paused the write-up to implement OIDC first. Almost every commercial IdP ships OAuth and OIDC together; reading vendor pricing without knowing what an id_token would not be correct. With v07 done, the OAuth+OIDC spine is complete enough to read the landscape.

Adding OpenID Connect on Top of OAuth 2

Sat, 20 Jun 2026 00:00:00 +0000

Why v06 is not enough #

v06 split the authorization server from the resource server and taught token validation across process boundaries. That is production-shaped OAuth 2.0.

It is not OpenID Connect. Vendors market themselves as OpenID Providers because OIDC standardizes authentication (who logged in) on top of OAuth’s authorization (what APIs this token may call). While technically it’s not part of OAuth 2 specs; and I had steered clear of implementing it; I decided to tackle this as well since I was working on a piece that covered what’s available out there and what their business was. In almost all cases IdP (Identity providers) implement OIDC on top of OAuth.