What is OneLogin?

OneLogin is Giftem's own identity provider — our "Sign in with Giftem". One account, one login, shared across every application that connects to it. The same idea as "Sign in with Google", except we own it: our users, our rules, our security, on our infrastructure.

How it works

Applications never see or store a user's password — in fact, most users never need one at all. When someone clicks "Sign in with Giftem", the application sends them here; OneLogin handles the login (sign in with an emailed code — password optional) and hands back a sealed, digitally-signed token proving who they are. Walk into a second connected application and the login is already done — that's single sign-on. The protocol underneath is OpenID Connect, the same standard Google, Microsoft and Apple use for their sign-in buttons, so any standard library can integrate (see the integration guide).

What it has today

✓ Hosted, tenant-branded login pages — email-first sign-in, registration with real email verification, and a persistent TEST MODE badge on sandbox tenants
✓ Sign in with an emailed code — password optional. Registration only ever asks for a name and an email; one emailed code confirms it and signs you in, no password to create or remember
✓ Choose to add a password later — from your account page in any connected app, or via a password reset — for a traditional password-plus-email-code login instead — "trust this device for 30 days" then skips the code, never the password, and only ever applies to a password-holding account that still asks for its password
✓ Single sign-on across applications, plus a standard "use a different account" switch (OIDC prompt=login)
✓ Single sign-out — confirming "Sign out" on the Giftem ID page ends your session and revokes the access issued to every connected application, on all your devices (an application may take up to 15 minutes to notice). When an application asks us to sign you out on its own, only that application's access is ended
✓ A consent screen naming the application, the signed-in account, and exactly what's shared — skippable only for our own first-party apps
✓ Self-service password reset via an emailed, single-use link — signs the account out everywhere once it's used
✓ "Continue with Google or Facebook" — connected once here, inherited by every application; an existing account is linked only when the provider vouches for the email or after an emailed confirmation code, and the one-time email code still applies afterward
✓ Manage your Giftem ID from any connected app: set or change your password, add a US mobile number and verify it by text, choose whether your sign-in codes arrive by email or by text, and choose whether your password is asked at sign-in or a code alone is enough
✓ …and, once you've chosen text codes, sign in by entering your mobile number instead of your email — on a device you've already trusted, the text is skipped and only your password is asked

For companies and integrators

✓ Multi-tenant by construction: each company's users live behind their own wall, and every tenant gets an automatic sandbox twin for safe testing (plain-http redirects to localhost and .test / .localhost development hosts allowed there, and only there)
✓ Standard OpenID Connect surface: discovery document, JWKS, authorize / token / userinfo, signed JWTs, rotating refresh tokens
✓ A connected application can sign a user out of itself everywhere — one authenticated call revokes that application's tokens for that user on every device (it may take up to 15 minutes to notice), without touching their other applications or their Giftem ID session
✓ Applications with a one-time credential reveal, secret rotation with a chosen overlap window (or immediate), and an on/off switch enforced at both the login and token steps
✓ Admin panel for provisioning tenants and applications in guided steps, including editing a tenant's name after the fact
✓ Admins can act directly on a stuck end user — force logout, unlock, resend verification, mark verified, suspend, or delete an account — without reaching into the database
✓ Sandbox tenants capture their outgoing mail for inspection instead of delivering it, so test integrations can complete sign-up/sign-in flows with fake addresses
✓ A private, expiring, revocable developer inbox link per sandbox tenant, so an outside integration team can read its own test sign-in codes without an admin account
✓ A developer portal for integrating teams: an administrator invites a team's developers, who sign in separately from admins to see their applications, read their sandbox test inbox, manage their sandbox redirect addresses within limits an administrator sets, and rotate their sandbox client secrets. On live applications they ask for redirect-address changes and an administrator approves them; where an administrator has switched it on for a tenant (off by default), they can also rotate a live client secret with their password and an emailed code. See the developer guide
✓ Browsable admin viewers for users, audit trail, authentication events, and captured sandbox mail, and a read-only system status page
✓ A built-in "Try it" test run that proves an application's configuration end to end (sign-in, tokens, userinfo) straight from the admin panel
✓ A public Try-it console on the integration guide — call the endpoints with sandbox credentials straight from the docs

Security, built in

✓ Fail-closed tenant isolation: code that forgets to scope a query errors out — it can never silently show another company's data
✓ PKCE (S256) required on every single authorization — no downgrade accepted
✓ Stolen-token tripwire: each refresh token works once. If a used one, or a used sign-in code, is presented again, every sign-in that account has with that application is ended and the attempt is logged. A repeat within 60 seconds of the refresh (say, a response that got lost) is refused without ending the other sessions
✓ Everything sensitive stored hashed: passwords, one-time codes, client secrets, trusted-device tokens
✓ Per-tenant rate limits, account lockouts, single-use short-lived codes with strict attempt caps
✓ Bot protection (Cloudflare Turnstile) on registration, sign-in, password-reset requests, and code resends
✓ Any password a user does choose to set is screened against known data breaches and rejected if compromised
✓ Account lockout after repeated wrong codes, not just wrong passwords — a sign-in code is a real credential and is defended like one
✓ Sign-in codes by email or, once a US mobile number is verified, by text — with an automatic fallback to email if a text can't be delivered
✓ An email alert whenever a sign-in completes from a device the account hasn't trusted yet
✓ An automatic alert email to the account holder when repeated failed sign-ins temporarily lock the account
✓ Hardened admin access: separate accounts, mandatory email-code 2FA with no trust-device bypass, idle and absolute session timeouts, account lockout after repeated failed sign-ins with an alert email, and password re-confirmation before destructive actions
✓ Hardened developer access: invitation-only accounts, a mandatory emailed code at every sign-in with no trust-device bypass, idle and absolute session timeouts, lockout with an alert email, access scoped to the team's own tenant (anything else is simply not found), password re-confirmation on every change, and no live redirect address changes without an administrator's approval
✓ Multiple admin accounts with a read-only Viewer role, invited by email link — never created with a password in transit — and a disable-never-delete policy that keeps the audit trail intact
✓ End-user sessions expire after 30 minutes of inactivity and after 12 hours in total, however active — an over-age session can't silently sign in to another application
✓ A complete audit trail — every administrative change and every authentication event is recorded
✓ Strict security headers and content-security policy; no third-party scripts beyond Cloudflare's bot check
✓ Independently reviewed: multiple adversarial security audit passes, with every blocking finding fixed and re-verified live, backed by automated end-to-end and security test suites

Rolling out now

Passkey sign-in (Face ID, Touch ID, Windows Hello, a security key) is built and tested, arriving once our own domain is live — a passkey is tied to the domain it was created on, so we're waiting for that before switching it on. Planned next, after v1 wraps: authenticator-app 2FA and a PHP SDK.

Where to go next

Setting up a client as an admin? Start with the admin guide. Connecting an application? The integration guide has working code for any PHP app. Invited to the developer portal? Read the developer guide.