Hands-on OIDC class surfaced

A software engineering thread making the rounds assigns students an unusually concrete job: build OpenID Connect yourself instead of only wiring up a login button. (openid.net) OpenID Connect is the identity layer on top of OAuth 2.0, the web standard that lets one service ask another for limited access. In practice, it is the protocol behind many “Sign in with Google” flows and the ID token that tells an app who the user is. (openid.net) (developers.google.com) Google’s implementation publishes a discovery document that lists its OpenID Connect endpoints, including where clients should send users and where they can fetch public signing keys. That metadata is standardized through OpenID Connect Discovery and OAuth 2.0 Authorization Server Metadata. (developers.google.com) (openid.net) (rfc-editor.org) Those public keys matter because most OpenID Connect systems use asymmetric cryptography: the identity provider signs a token with a private key, and the app verifies it with a public key. The key format is standardized as JSON Web Key, and the token format is standardized as JSON Web Token. (rfc-editor.org 1) (rfc-editor.org 2) That is the part many developers skip over when they use a library. A build-it-yourself exercise forces them to see the moving parts behind single sign-on, including redirects, token exchange, signature checks, issuer validation, audience checks, and key rotation. (openid.net) (developers.google.com) The thread also reportedly walks through a common architecture question: whether authentication logic should live inside one large application or be split into separate services. That trade-off usually turns on operational complexity, because a monolith reduces moving pieces while microservices can isolate identity flows and scale them independently. (developers.google.com) (github.com) Hands-on OpenID Connect material is harder to find than conceptual explainers because production systems usually rely on managed identity providers, SDKs, and framework adapters. Official documentation from Google and other vendors focuses on integrating an existing provider, not re-creating one from scratch. (developers.google.com) (docs.cloud.google.com) That leaves a gap for interview prep and system design. Engineers are often expected to explain how single sign-on works, how an ID token differs from an access token, and how an app verifies signatures without ever seeing the provider’s private key. (openid.net) (rfc-editor.org 1) (rfc-editor.org 2) A class that turns those ideas into an end-to-end exercise gives students a way to practice the protocol as infrastructure, not just as a product feature. For authentication systems, that is often the difference between knowing the acronym and knowing what the login flow is actually doing. (openid.net) (developers.google.com)