Zero password handling.
Clearer responsibilities.

Social sign-in can remove the need to build a password database for that login flow. It does not remove the need to protect identity data, tokens, or sessions—or establish automatic legal compliance.

Research reviewed October 5, 2026. This guide explains applicability and the current implementation; it is not a compliance attestation.

What AnyOAuth handles

No provider passwords. Users enter credentials with their identity provider. AnyOAuth’s sign-in API does not collect or store those passwords or password hashes.
Identity information is stored. The database stores normalized profiles, provider IDs, project-scoped subjects, names, emails, avatars, and sign-in timestamps where supplied. These remain personal data.
Provider tokens are transient. Provider tokens are used server-side during the sign-in request; they are not persisted or returned to customer applications.
AnyOAuth tokens are separate. Profile tokens expire after 15 minutes and are stored as hashes. Client secrets and dashboard session tokens are also stored as hashes.
Deletion has a defined boundary. Deleting a project user removes the identity and its dependent profile tokens and handoff codes from the application database. This does not delete customer-app data or the upstream provider’s account.

Expired transaction, handoff-code, token, session, and rate-limit rows are cleaned up by the scheduled job. Identity profiles are not automatically deleted just because a token expires. Backup retention, data locations, subprocessors, processing agreements, and operational rights procedures must be documented separately.

Relevant to identity information, not only passwords. GDPR can apply to EU establishments and to certain services offering goods or services to, or monitoring, people in the EU. There is no general small-business revenue exemption. UK GDPR is a separate regime with its own territorial and transfer rules.

A customer often acts as controller for its user accounts; a service processing profiles on its instructions may act as processor. Roles depend on the actual purposes and decisions, including separate uses for the service’s own accounts.

Applicable responsibilities include a lawful basis, privacy notices, purpose limitation, data minimization, retention, access and deletion rights, appropriate security, processor terms, and lawful international transfers. A provider’s permission screen does not authorize every downstream use of an email address.

Read the GDPR (especially Articles 3, 5, 13, 17, 28, 32 and Chapter V) · EDPB small-business guide · UK GDPR scope

CCPA / CPRA: California privacy

Applies when statutory coverage or service-provider duties are triggered. CPRA amended the CCPA; these are not two separate compliance badges.

Ordinary business coverage includes doing business in California and meeting a statutory threshold: annual gross revenue above the current adjusted $26.625 million threshold; annually buying, selling, or sharing personal information of at least 100,000 consumers or households; or deriving at least 50% of annual revenue from selling or sharing personal information. Simply having 100,000 users is not the same test.

A smaller vendor can still have service-provider or contractor responsibilities when serving a covered business. Relevant duties include notices, appropriate collection and retention, rights handling, contract restrictions, and reasonable security. Your app’s analytics, advertising, and use of identity information need their own analysis.

California Privacy Protection Agency FAQ · Current monetary thresholds · CCPA statutory text

Password security: NIST, OAuth & OWASP

The immediate developer benefit is avoiding local password management. For apps using only this social sign-in flow, there is no need to maintain an end-user password-verifier database or password-reset flow. A provider may still use passwords or other authenticators; social sign-in does not guarantee MFA or phishing-resistant authentication.

AnyOAuth’s product direction is password-free: social sign-in and planned email magic links, with no password-login feature. Email magic links are not implemented yet. Identity, email-link tokens, account recovery, and sessions still require protection.

For applications that maintain password login outside AnyOAuth, NIST SP 800-63B-4 calls for salted, attack-resistant password hashing and other verifier protections. Plain hashing of a high-entropy random API token is not a suitable pattern to copy for human passwords.

NIST’s federation guidance, OAuth’s security best current practice (RFC 9700), OpenID Connect, and OWASP ASVS are useful engineering references. Using these protocols is not, by itself, proof of conformance to every requirement.

NIST password-verifier requirements · NIST federation guidance · OAuth security BCP · OWASP ASVS

PCI DSS: payment-security scope

PCI DSS is not a general user-profile storage standard. It addresses payment account data and services that can affect the security of a cardholder-data environment. An authentication service may be in scope if it controls access to that environment—even without storing card numbers.

Outsourcing sign-in does not remove applicable customer duties. Assess the integration’s scope, the provider/customer responsibility split, and required evidence. AnyOAuth does not claim PCI DSS validation on this page.

PCI SSC: providers affecting payment security · PCI SSC: third-party responsibilities

SOC 2 & ISO 27001: enterprise assurance

Useful for supplier evaluation when buyers require evidence. SOC 2 Type II is a CPA attestation report covering controls and operating effectiveness over a period, not a certification. ISO/IEC 27001 certification covers a defined information security management system scope.

Neither automatically makes a customer application compliant with privacy laws. No AnyOAuth SOC 2 report or ISO 27001 certificate is asserted here. HIPAA requires a separate assessment for healthcare data and applicable business-associate relationships.

AICPA SOC overview · ISO/IEC 27001 · HHS healthcare service guidance

Your app still owns its data use

Protect your sessions and permissions, document how you use profile data, choose appropriate retention, and handle user rights across your own systems. Provider app registrations, privacy notices, processing terms, deployment controls, and data-transfer arrangements all matter alongside the authentication code.

For the current technical boundaries, read the security model. For the supported sign-in flow, read the integration quickstart.

Zero password handling.Clearer responsibilities.