Security requirements for MIX ID integrations

Use PKCE S256, one-time state/nonce, exact registered redirect URIs, signature/claim validation and least-privilege scopes. Backend authorization remains your application’s responsibility; an SDK cannot elevate trust tier.

Provider and Hosted Auth use separate directories/consent policies. Matching email is not identity proof; link accounts through an explicit safe flow.

Native FIRST_PARTY browser cookie sessions do not replace the external OAuth contract. Do not copy internal Account/Console endpoints into your client library. Access tokens and ID tokens have different purposes. Handle refresh rotation/reuse, logout and failed callbacks deliberately. Never place a client secret in JavaScript or publish gateway secrets, private keys or real tokens in examples.

Offline JWT verification checks signature/claims, not the current revocation state of a sid. A trusted gateway identity envelope also needs audience, method/path, freshness and replay policy at the service boundary. Do not accept identity headers from arbitrary internet clients.

Public documentation does not imply a generic signing API, arbitrary Channel RPC, SAML/SCIM/LDAP or certified AAL3. Planned features remain distinct from delivered contracts. Use the repository/vendor private security reporting channel rather than posting credentials or personal payloads in a public issue.