Clarify that account status changes (disabled) may surface as access_denied during provider login/authorization, and integrations should handle these outcomes explicitly.
Extend SDK integration guidance to cover provider-side active-state enforcement at token issuance, where invalid_grant may be returned if client/user/project is inactive.
Document that integrations must not mix HTTP Basic and client_secret form authentication on the same token/control endpoint request, aligning with provider-side hardening.
Add integration guidance that provider abuse controls can apply across related auth endpoints based on source identity, reinforcing backoff and retry discipline.
Update SDK example callback and integration guidance to treat UserInfoException as an authorization-state outcome (e.g. subject disabled/inactive scope) and return a clear 403 path.
Align SDK integration guidance with provider redirect URI hardening: use HTTPS callback URLs in production and limit HTTP callbacks to localhost loopback during development/testing.
Update integration guidance so consuming apps treat access_denied as an expected provider authorization result when membership or privilege state changes during the OAuth consent flow.
Document that integrations should expect provider-side abuse controls on OAuth control endpoints and handle 429 responses with retry/backoff semantics.
Clarify that providers may return access_denied at callback time even after consent UI is shown, when membership/tenant scope changes before consent submission. This aligns integration guidance with current provider-side security enforcement.
Update SDK docs and example callback handling to process provider callback errors explicitly. access_denied is now documented and handled as an expected authorization outcome (HTTP 403), including cases where provider membership/scope checks fail at consent submission.
Andy Dixon
Andy Dixon