auth/oauth presets Google, Microsoft, GitHub and Discord by name. Shipping a preset is a claim that the library works with that provider, and today that claim rests entirely on having read their documentation — every fixture in the test suite is one I wrote from the spec.
Originally this issue proposed running the full Authorization Code flow against live providers. That was the wrong scope, and the owner was right to push back: the full flow is the consumer's business. They register their own application, hold their own client secret, and a human has to click "allow" in a browser. Testing it with our credentials would prove Google works, not that this library's API is right, and a manual pre-release procedure gated on a third party's uptime is recurring cost for a snapshot that goes stale the following week.
What is not the consumer's business is the part we ship: the parsing of what those providers actually send.
The part that can be verified, with no credentials at all
Discovery documents and JWKS are public. Fetched anonymously just now:
| endpoint |
result |
accounts.google.com/.well-known/openid-configuration |
200, 17 fields |
login.microsoftonline.com/common/v2.0/.well-known/openid-configuration |
200 |
googleapis.com/oauth2/v3/certs |
4 keys, all RSA / RS256 / use=sig |
login.microsoftonline.com/common/discovery/v2.0/keys |
8 keys, carrying x5c, x5t, issuer and cloud_instance_name besides the standard fields |
That last row is exactly the kind of thing hand-written fixtures never contain — Microsoft attaches a per-key issuer, which no spec-derived fixture of mine has.
Scope
Capture those documents as committed fixtures and run Discover and the JWKS parser against them. No client id, no secret, no browser, no third-party uptime in CI — they are static files in the repository.
Worth asserting per provider: discovery resolves and yields the endpoints the preset hardcodes (which is the preset's actual claim); every key in the real JWKS parses; unknown fields are ignored rather than rejected; and the advertised signing algorithms are ones this module accepts.
What this does not cover, honestly: the token exchange and validating an ID token they signed. That needs credentials and consent, and it stays the consumer's to exercise.
And what it does not solve: a fixture proves the parser handles what a provider sent on the day it was captured. Providers change. This is a regression baseline, not a liveness check — resist turning it into a scheduled job that fetches live, because an informational lane that goes red when someone else has a bad afternoon is a lane people learn to ignore.
The alternative, if the presets are not worth this
Stop making the claim. Drop the presets and document that the consumer configures endpoints themselves. That is a legitimate resolution: an assertion you cannot verify has two honest outcomes, verify it or stop asserting it.
auth/oauthpresets Google, Microsoft, GitHub and Discord by name. Shipping a preset is a claim that the library works with that provider, and today that claim rests entirely on having read their documentation — every fixture in the test suite is one I wrote from the spec.Originally this issue proposed running the full Authorization Code flow against live providers. That was the wrong scope, and the owner was right to push back: the full flow is the consumer's business. They register their own application, hold their own client secret, and a human has to click "allow" in a browser. Testing it with our credentials would prove Google works, not that this library's API is right, and a manual pre-release procedure gated on a third party's uptime is recurring cost for a snapshot that goes stale the following week.
What is not the consumer's business is the part we ship: the parsing of what those providers actually send.
The part that can be verified, with no credentials at all
Discovery documents and JWKS are public. Fetched anonymously just now:
accounts.google.com/.well-known/openid-configurationlogin.microsoftonline.com/common/v2.0/.well-known/openid-configurationgoogleapis.com/oauth2/v3/certsuse=siglogin.microsoftonline.com/common/discovery/v2.0/keysx5c,x5t,issuerandcloud_instance_namebesides the standard fieldsThat last row is exactly the kind of thing hand-written fixtures never contain — Microsoft attaches a per-key
issuer, which no spec-derived fixture of mine has.Scope
Capture those documents as committed fixtures and run
Discoverand the JWKS parser against them. No client id, no secret, no browser, no third-party uptime in CI — they are static files in the repository.Worth asserting per provider: discovery resolves and yields the endpoints the preset hardcodes (which is the preset's actual claim); every key in the real JWKS parses; unknown fields are ignored rather than rejected; and the advertised signing algorithms are ones this module accepts.
What this does not cover, honestly: the token exchange and validating an ID token they signed. That needs credentials and consent, and it stays the consumer's to exercise.
And what it does not solve: a fixture proves the parser handles what a provider sent on the day it was captured. Providers change. This is a regression baseline, not a liveness check — resist turning it into a scheduled job that fetches live, because an informational lane that goes red when someone else has a bad afternoon is a lane people learn to ignore.
The alternative, if the presets are not worth this
Stop making the claim. Drop the presets and document that the consumer configures endpoints themselves. That is a legitimate resolution: an assertion you cannot verify has two honest outcomes, verify it or stop asserting it.