An identity provider written by hand

The problem

Configuring an identity provider without knowing what it must refuse is configuring it blind. I wanted to know exactly which attack each rule stops.

What I built

• Authorization code flow with mandatory PKCE; JWTs signed with RS256, verification keys kept for the lab's own applications and rotated without downtime; rotating refresh tokens.
• Two-factor authentication with TOTP, compatible with Google Authenticator.
• One SSO session shared by four applications: a confidential client, a single-page app (PKCE only), Grafana and GitLab.

Choices and reasons

• An SSO account is never linked to an existing Grafana or GitLab account, by name or by e-mail: it is recognised by a random identifier.
• No e-mail address is collected: the server provides a technical address under .invalid (RFC 6761) that cannot match any account.
• Names such as admin or root are refused at sign-up; Grafana only grants the Viewer role, GitLab an external account; demo accounts are deleted after 24 hours.

Checked

• 33 tests, run in every pipeline, check each attack the server must refuse.
• With a scripted browser, live: the password and TOTP code typed once, then Grafana and GitLab only asked for consent. An account named "admin" got a separate, read-only Grafana account.

Limits and next steps

Written to learn, not to replace a proven product. The code lives in a private repository.