Applogin — unified sign-in

Add Google and email/password sign-in to your application with one script. All authentication — sign-in, sign-up, email verification, password reset, Google — happens inside a protected iframe on applogin.one. Your page never sees the user's password and never validates anything — you only receive a ready-made app-scoped token.

How it works

Applogin is an authentication provider (like Auth0/Clerk), but the login form is served in a frame from our domain. Your app opens that frame (in a modal) through the SDK and receives the result via postMessage. The token is a JWT signed with your application's secret (aud=app_id), so it is useless in any other application.

Quick start

Include two scripts and mount the widget — it silently tries SSO, shows a "Sign in" button, opens the hosted form in a frame and returns the user.

<script src="https://applogin.one/applogin.js?v=1"></script>
<script src="https://applogin.one/applogin-ui.js?v=1"></script>
<script>
  ApploginUI.mount({
    appId: "app_your_id",
    onAuth:   (user) => renderApp(user),  // signed in: { id, email, name, picture, email_verified }
    onLogout: ()     => showLanding()
  });
  // sign-out button:  ApploginUI.logout();
</script>

That's it. The form, registration, email codes, Google and password reset are all handled by Applogin. The only requirement is to register an app_id and list your allowed_origins (see Creating an application).

The ApploginUI widget recommended

A ready-made "lock" for your app: while signed out it shows a screen with a "Sign in" button; a click opens the hosted form in a modal; after sign-in it calls onAuth(user) and removes the screen.

You render the profile (avatar, name, email) and the sign-out button yourself from onAuth(user) — that is your UI. The user data arrives ready to use.

SDK methods (applogin.js) low level

If you want your own UX instead of the widget, use the SDK directly. Call Applogin.init({ appId }) first. The token is stored in localStorage under al_token_<appId>.

Applogin.init({ appId: "app_xxx" });

// on load — silently try SSO:
const s = await Applogin.getSession();
if (s.authenticated) showApp(s.user);
else {
  const r = await Applogin.openLogin();     // modal with the applogin.one form
  if (r) showApp(r.user);
}
// attach Applogin.getToken() to your backend requests

Single sign-on (SSO)

On sign-in Applogin sets the al_sso cookie with the Partitioned attribute. The partition key is the top-level site (the outermost one). Therefore:

• Several of your apps under one site (e.g. embedded into appdock.pro) share the session → getSession() in the second app picks the sign-in up without a form.
• The same app opened as a separate site (another top-level) is a different partition → the user signs in again.

const s = await Applogin.getSession();   // ← {authenticated:true,…} if a session exists in this partition
if (s.authenticated) showApp(s.user);

Languages

The hosted login form speaks 10 languages: English, Deutsch, Français, Español, Italiano, Português, 日本語, 한국어, 中文, Русский. By default it opens in the user's browser language (falling back to English), and the user can switch the language right in the form — the flag menu at the bottom.

• Forcing a language. Pass lang to the widget or the SDK: ApploginUI.mount({ appId, lang: "de" }) or Applogin.init({ appId, lang: "de" }) — the form opens in that language. Without the option the SDK sends the browser language automatically.
• Reading the choice back. The user may switch the language inside the form. The result of Applogin.openLogin() contains lang — the language the form was in at sign-in — so your page can follow it. The widget also persists it (localStorage al_lang), and the next form opens in it.
• Emails follow the form. Verification and password-reset emails are sent in the form's language.

Under the hood the form URL accepts ?lang=xx (a two-letter code from the list above) — the SDK passes it for you.

Live example: AppDock

appdock.pro is a "dock" launcher: one page that opens several applications in iframes. The applications live on their own domains:

Sign in to Email Writer inside the dock, then open Audio Recorder (also inside the dock) — the sign-in is picked up automatically: both run under the same top-level site appdock.pro, so they share one SSO partition.

1. The dock launcher (appdock.pro)

<button class="tile" data-src="https://emailwriter.online/">Email Writer</button>
<button class="tile" data-src="https://audiorecorder.info/">Audio Recorder</button>
<iframe id="frame" allow="microphone; clipboard-write"></iframe>
<script>
  document.querySelectorAll(".tile").forEach(t =>
    t.onclick = () => document.getElementById("frame").src = t.dataset.src);
</script>

2. An application (e.g. emailwriter.online)

<script src="https://applogin.one/applogin.js?v=1"></script>
<script src="https://applogin.one/applogin-ui.js?v=1"></script>
<script>
  ApploginUI.mount({
    appId: "app_emailwriter",
    title: "Email Writer — sign in",
    onAuth: (user) => {              // render the profile + the app
      header.textContent = user.name + " · " + user.email;
      app.hidden = false;
    },
    onLogout: () => { app.hidden = true; }
  });
</script>

3. App registration for this scenario

Each application lists its own domain + the dock domain in allowed_origins (frame-ancestors sees the nested frame's whole ancestor chain):

app_emailwriter → allowed_origins: ["https://emailwriter.online", "https://appdock.pro"]
app_recorder    → allowed_origins: ["https://audiorecorder.info", "https://appdock.pro"]
// redirect_uris (for Google): ["https://applogin.one/auth-callback.html"]

Verifying the token on your backend

Your frontend puts Applogin.getToken() in the Authorization header of its requests. On the backend there are two ways to verify it.

1. Via the platform endpoint revocation-aware

POST https://applogin.one/api/v1/session/verify
{ "app_id": "app_xxx", "token": "<JWT from Authorization>" }
// → { "valid": true, "user": { "id": 2, "email": "…", "email_verified": true, "name": "…", "picture": null } }
//   invalid/revoked (logout) → { "valid": false, "user": null }

2. Locally (HS256 with your jwt_secret) no network

// Node.js
const jwt = require("jsonwebtoken");
const claims = jwt.verify(token, process.env.APPLOGIN_JWT_SECRET, {
  algorithms: ["HS256"], audience: "app_xxx", issuer: "applogin"
});
// claims.sub — user id, claims.email, claims.email_verified

# Python
import jwt
claims = jwt.decode(token, APPLOGIN_JWT_SECRET, algorithms=["HS256"],
                    audience="app_xxx", issuer="applogin")

JWT structure

{
  "iss": "applogin",
  "aud": "app_xxx",          // your app_id
  "sub": "2",                // user id (as a string)
  "jti": "…",                // session id (for revocation)
  "email": "user@example.com",
  "email_verified": true,
  "name": "Jane", "picture": null,
  "iat": 1782194619, "exp": 1784786619   // ~30 days
}

Webhook (optional)

If an application sets a webhook_url, the platform sends it a signed POST with the verified identity on each successful Google sign-in — for server-side syncing in addition to the token.

const exp = "sha256=" + crypto.createHmac("sha256", WEBHOOK_SIGNING_SECRET)
  .update(ts + "." + rawBody).digest("hex");
if (!crypto.timingSafeEqual(Buffer.from(exp), Buffer.from(sig))) reject();

Creating an application

Applications are created in the closed dashboard at applogin.one/dashboard (sign in via Applogin itself). You provide:

You get back: app_id (public), jwt_secret (backend token verification), client_secret, webhook_signing_secret.

REST API — reference

Base: https://applogin.one/api. Below is what a builder actually needs. The email/password and Google-exchange endpoints are called by the hosted form itself — you never call them.

For the builder

Verify an app token on your backend (revocation-aware). { app_id, token } → { valid, user }.

Public application data (name, allowed_origins). Used by the hosted login page.

Internal (called by the hosted form/SDK, not by the builder)

Errors

{"error":"Invalid or expired code","message":"Invalid or expired code"}

Security

• The password is isolated. Input fields exist only inside the applogin.one iframe; the embedding site's JS cannot reach them. A builder cannot "sniff" the password.
• App-scoped tokens. The JWT is signed with the application's secret and carries aud=app_id — one app's token is invalid in another. A builder cannot enter someone else's app as their user.
• Token delivery only to your origins. The form posts the token via postMessage only to an origin from allowed_origins; the login page itself is served with Content-Security-Policy: frame-ancestors <allowed_origins> (anti-clickjacking).
• The global session is HttpOnly. The al_sso cookie is unreachable from JS; the builder only ever holds an app token.
• Anti-CSRF on SSO. /v1/session/sso issues a token only for Origin ∈ allowed_origins — a foreign site with the user's cookie gets nothing.
• Anti-bruteforce. Rate limits on login/reset/verify (per email and per IP).
• Passwords are hashed (PBKDF2); codes are hashed with a 10-minute TTL and an attempt limit; HTTPS everywhere; Google tokens are never stored. Google sign-in uses PKCE (S256) + state + nonce.

LLM cheat sheet

// include
<script src=https://applogin.one/applogin.js?v=1></script>
<script src=https://applogin.one/applogin-ui.js?v=1></script>

// mount (a lock on the app)
ApploginUI.mount({ appId, onAuth:(user)=>..., onLogout:()=>... });
ApploginUI.logout();

// low level
Applogin.init({ appId });
await Applogin.getSession();   // {authenticated, token, user} — silent SSO
await Applogin.openLogin();    // {token, user, lang}|null — modal with the form
Applogin.getToken(); await Applogin.verify(); await Applogin.logout();

// backend: verify the token
POST https://applogin.one/api/v1/session/verify {app_id, token} -> {valid, user}
// or locally: jwt.verify(token, jwt_secret, {algorithms:["HS256"], audience:app_id, issuer:"applogin"})

Applogin · unified sign-in · dashboard · live example: AppDock