Support Generic OIDC profiles from verified id_token claims

[salasebas]

Context

The Generic OAuth callback no longer accepts profile claims from id_token without verification. That closes the unsafe path where a token response or custom get_token hook could provide arbitrary sub/email claims and have them flow into account creation/linking.

Better Auth upstream 1.6.9 still allows genericOAuth to decode tokens.idToken as a profile source before userinfo. That appears to be a convenience/parity behavior, not a safe OIDC verification boundary.

Recommendation

Add explicit Generic OIDC support only if RustAuth can verify the id_token before using its claims as profile data.

The feature should require a deliberate OIDC configuration path, for example:

• discovery or explicit JWKS endpoint
• issuer validation
• audience/client_id validation
• expiration/not-before validation
• nonce validation when the flow issues a nonce
• algorithm/key validation with fail-closed errors

Non-goals

• Do not re-enable decode-only id_token profile extraction.
• Do not treat upstream's current decode behavior as sufficient validation.

Acceptance criteria

• A generic provider can opt into verified id_token profile extraction.
• Forged or unsigned id_token values are rejected.
• Wrong issuer/audience/nonce tokens are rejected.
• Existing userinfo_url and custom get_user_info behavior remains supported.

[salasebas]

Resolved by #186 (commit c0ebd53).

That implementation added the explicit VerifiedIdToken profile source with JWKS/signature verification, issuer and audience checks, standard claim/expiration validation, nonce binding, authorized-party handling for multiple audiences, and fail-closed regression tests while preserving UserInfo and custom get_user_info.

#204 is intentionally not used to close this issue because it reintroduces decode-only profile extraction, which contradicts this issue's non-goals. Residual OIDC hardening around strict azp handling and nonce propagation through the generic social-provider path will be evaluated separately.