Sign in with Google, and proof that it is really them

security/social sits on top of security/OAuth2 and does one job: build the authorize URL, then turn the callback code into a verified profile. Google, Microsoft and Apple. No user handling, no session, no routes; that stays with your app.

It started in factuur.software, where a Google button beside the login form was the actual requirement. Once three more apps wanted the same button, the flow moved to the engine and the verification got the attention it deserves. The id_token is now checked against the provider's JWKS before a single claim is read: RS256 only, key looked up by kid, on top of issuer, audience matching your client_id, expiry and, when you supply one, the nonce. The JWK to PEM conversion is written out by hand so the resource stays dependency-free.

The most useful part is what verified reports: what the provider actually proved, not what it merely sent. Google states email_verified. Microsoft omits it, so an address counts as proven only when the optional xms_edov claim says the tenant owns it. Treat an unverified email as a claim and match your users on provider plus sub, which is the identifier that cannot be reassigned.

A provider with no credentials in data/creds.ini is simply unavailable, so a node offers whichever buttons it holds keys for. In use in factuur.software, logbook.tools, flysight.video and teslacam.online.

Engine 1.0.1. See Social login in chapter 12.