[codex] Add opt-in unverified generic OAuth ID token mode

[salasebas]

Summary

• adds GenericOAuthProfileSource::UnverifiedIdTokenThenUserInfo as an explicit opt-in Generic OAuth profile source
• decodes id_token payload claims without signature verification only in that opt-in mode, requiring usable sub and email claims before mapping
• keeps the default UserInfo path and the verified VerifiedIdToken(...) OIDC path unchanged
• documents the Better Auth parity tradeoff and adds provider/route regression coverage

Context

Better Auth 1.6.9 decodes Generic OAuth idToken profile claims before falling back to userinfo. RustAuth keeps the secure default, but this adds a deliberately named opt-in mode for maintainers who need that upstream-compatible behavior.

Closes #178.

Validation

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo nextest run -p rustauth-plugins --all-features generic_oauth
• cargo nextest run -p rustauth-plugins --all-features

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
rustauth-docs-site	Ignored		Jul 3, 2026 6:32am

[salasebas]

Closing without merge after audit.

RustAuth intentionally removed decode-only Generic OAuth ID-token profile extraction because unverified sub, email, and email_verified claims can cross the account-linking/session trust boundary. #186 already implemented the safe solution requested by #178 through explicit VerifiedIdToken verification (JWKS/signature, issuer, audience, expiration, nonce, and fail-closed tests).

Although Better Auth 1.6.23 still contains the legacy decode-only behavior, its next branch is moving discovery-backed Generic OAuth toward verified ID tokens and nonce binding in better-auth/better-auth#9966 and better-auth/better-auth#10095. Adding a new public unsafe mode here would therefore reverse RustAuth's existing hardening and contradict #178's stated non-goals.

If compatibility with a provider that cannot expose trustworthy UserInfo/JWKS is needed later, it should be designed in a separate issue with an explicit threat model rather than treating unverified JWT payloads as authenticated identity.