EmbedAuth is built for developers who care about the security of their users. Here's how we protect your data at every layer.
Defense in depth across every layer of the stack.
EmbedAuth is served over HTTPS with HSTS. Passwords are hashed with bcrypt at cost 12, and client secrets, refresh tokens, magic links and one-time codes are stored only as hashes. Secrets the service has to read back — JWT signing keys, webhook signing secrets and reCAPTCHA keys — are encrypted with AES-256-GCM.
Sign-in, sign-up and account-recovery endpoints are rate-limited per IP address, and endpoints that send email are also limited per email address. Ten wrong passwords in a row lock an account for five minutes. Successful and failed sign-ins are recorded as auth events.
EmbedAuth issues short-lived JWTs signed with RSA private keys (RS256). The corresponding public keys are exposed via the JWKS endpoint for server-side verification — no shared secrets, no symmetric keys.
Dashboard sign-ins and changes to apps, themes and team membership are written to an organization audit log with who did it and when. End-user sign-ups and sign-ins are recorded separately as auth events with IP address and user agent.
Each app has a list of allowed domains. The widget posts tokens only to a page on one of them, using that page's exact origin as the message target, so a site that copies your embed code receives nothing. Redirects after sign-in are limited to the same list.
Every query is scoped to the organization and app it belongs to, and dashboard permissions are checked on the server for each request. End users of one app are never visible from another. Database credentials stay in the server environment.
Refresh tokens are single-use, and presenting a spent one revokes every token from the same sign-in. Each active session is listed in the dashboard with its user, IP address, browser and expiry, and any one of them can be revoked there.
The widget is served with a Content-Security-Policy that allows only its own script and Google reCAPTCHA. Every other EmbedAuth page refuses to be framed by other sites. We recommend setting `frame-src` in your own CSP to scope iframe embeds to EmbedAuth's hosts only.
A checklist of the security controls enforced across all EmbedAuth deployments.
Set this header on pages that embed the EmbedAuth iframe to restrict framing to your EmbedAuth origin only.
# HTTP response header Content-Security-Policy: frame-src https://embedauth.com https://cdn.embedauth.com; # Or as a <meta> tag <meta http-equiv="Content-Security-Policy" content="frame-src https://embedauth.com https://cdn.embedauth.com;">
Both hosts are required: the iframe URL points at embedauth.com, which redirects to the static CDN at cdn.embedauth.com. CSP enforces frame-src on every hop of the redirect chain. Self-hosters should substitute their own auth and CDN hostnames.
We take security vulnerabilities seriously. If you discover a potential security issue, please disclose it responsibly by emailing [email protected]. Include a description of the vulnerability, steps to reproduce, and your contact details.
Start for free. Upgrade when you need more scale.