Oauth2 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.

Splitting the Auth Server from the Resource Server

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

Why v05’s single process is not the finish line #

v05 closed the refresh loop: short-lived access tokens, silent renewal via grant_type=refresh_token, and a protected GET /api/me. One convenience hid an architectural lie.

In v05, the authorization server and resource server share one Flask process on :25000. The client calls the same host for POST /token and GET /api/me. Token minting and token validation both read memory.access_tokens in the same Python dict. That works in a toy lab; it is not how production OAuth is deployed.

Refresh Tokens and Silent Re-authentication

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

Why v04 was not the finish line #

v04 closed the loop through a protected API: the client app stores an access_token, calls GET /api/me with Authorization: Bearer …, and shows a profile page. Login means the token works and the resource server agrees.

That token has a TTL. v04 minted access tokens with expires_in: 3600. In production, short-lived access tokens are deliberate: if one leaks, damage is bounded. When it expires, /api/me returns 401 and the user would otherwise go through /authorize again: browser redirect, login form, callback.

Using the Access Token on a Protected API

Wed, 10 Jun 2026 00:00:00 +0000

Why v03 was not the finish line #

v03 closed the authorization half of OAuth: state for CSRF, PKCE for code interception, and POST /token to mint an access_token. After a successful login, the callback page displayed that token as a string.

That is a useful checkpoint. It is not a complete application experience. The token is supposed to be a credential. Something has to accept it and return data only the authenticated user should see.

Adding PKCE to Stop Authorization Code Interception

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

Why v02 needed a fix #

v02 closed the login CSRF hole. The client generates random state, the auth server echoes it on the callback, and the client rejects mismatches. That answers: “Did I start this login?”

It does not answer a different question: “Is the person trying to redeem this code the same app that requested it?”

The authorization code itself is a secret, but for a short time. It travels in the browser redirect URL:

Adding OAuth State to Stop CSRF

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

Why v01 needed a fix #

v01 got the Authorization Code redirect working, but it deliberately left out OAuth state. That absence is fine for learning the spine of the flow; it is not fine for anything you would ship.

The next piece to add is a mechanism to stop CSRF (Cross-Site Request Forgery). CSRF is when a site you are on tricks your browser into making a request you did not mean to make. The browser automatically sends along your cookies and session, so the server thinks you did it. RFC 6749 §10.12 calls this out for the authorization endpoint.

Learning OAuth 2 by Building It, One Version at a Time

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

A preamble #

What is my motivation behind this #

Andromeda has been working on creating a comprehensive solution around Agents. If we look past the hype, the buzzword, and the scepticism, Agents and Agentic AI are here to stay and security is a real concern. Anthropic came up with an initial specification for something called Model Context Protocol (MCP), which has eventually become a standard. The standard specifies OAuth 2.1 as the authorization mechanism.