Add Sign in with Realr.

https://www.realr.me/.well-known/openid-configuration

GET https://www.realr.me/oauth/authorize
  ?client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.com/auth/realr/callback
  &response_type=code
  &scope=openid profile email trust
  &state=...&nonce=...

• Default scopes: openid profile email trust — a stable account id, name/handle/photo, email, and verification status. That’s a proven, verified user on day one.
• One human, one account — dedupe on sub. The sub claim is a stable, unique id for the Realr account — the same person returns the same sub on every sign-in. Store it with a unique constraint and, on sign-in, look the user up by sub and log into the existing account instead of creating a new one. (Like “Sign in with Google”, we guarantee a stable id; enforcing one-account-per-id is the app’s job.) This is what keeps “Verified via Realr” meaning one real person.
• The user is always in control. The consent screen lists exactly what you’ll see; anything sensitive is opt-in and off by default.
• Endpoints: /oauth/authorize · /api/oauth/token · /api/oauth/userinfo · /oauth/jwks (RS256).

GET https://www.realr.me/api/v1/trust/vintagevault

{
  "handle": "vintagevault",
  "displayName": "Vintage Vault",
  "accountType": "business",
  "profileUrl": "https://www.realr.me/vintagevault",
  "verified": true,
  "trust": { "level": "established", "label": "Established reputation" },
  "verifications": [
    { "type": "email",         "label": "Email verified",         "since": "2024-09-10T00:00:00Z" },
    { "type": "government_id", "label": "Government ID verified", "since": "2024-09-12T00:00:00Z" }
  ],
  "badges": ["identity_verified", "verified_human"],
  "legalNameVerified": true,
  "memberSince": "2024-09-10",
  "version": "1"
}

• Claims only. Verification badges + a sentence-form trust level — never a numeric score, never raw ID numbers, dates of birth, or the legal-name value.
• Privacy carries through. Anything a user keeps private on their profile is absent here too.
• 404when the handle doesn’t exist or the profile is private. Cached ~60s.

<script
  src="https://www.realr.me/widget.js"
  data-handle="vintagevault"
  data-variant="reputation"
  data-theme="light"
  async
></script>

Variants: minimal (the verified pill), reputation (adds a trust line), dynamic (profile card with level). Themes: light / dark.

https://www.realr.me/signup?ref=cuepop

Add ?ref=your-platform for attribution. Once they finish, poll the Trust Status API (or, soon, subscribe to a webhook) to reflect their new status.

• You can’t match your users against another app’s

  Every app gets its own opaque subject ID for the same person. Two services that both use Realr, comparing their full user tables, cannot find a single row in common. Realr is not a correlation key.

• You can’t quietly widen what you receive

  The consent screen splits what your flow genuinely needs from what is optional, and a person can decline the optional half and still connect. Scopes are checked against what Realr approved for your client — a tampered form cannot grant more than that.

• You can’t read a document, a legal name, or a date of birth

  Realr returns claims, never the underlying values. “Over 18” is a claim; a date of birth is not on offer at any tier.

• You can’t use it without leaving a record

  Every consent, token and read is logged by scope name — and never by value, because an audit trail holding the email it released would be a second copy of the data it exists to police.

Existing integrations predating pairwise subjects keep the subject they were issued; moving one is a coordinated change, never a silent re-key.

• email / phone — a reachable contact (OTP). Anti-spam, not identity.
• selfie (“real person”) — a live human, liveness-checked. Kills bots and AI fakes.
• government_id — identity + age (18+) + location, reviewer-matched to the live face. The strongest anchor; the document itself is never exposed.
• verified_photos — photos matched to the live face. Anti-catfish.
• gst / company_registration — a registered business.
• couple_verified — a mutually verified pair.

Requiring a level: read realr_trust_level / realr_verifications and gate on your side — e.g. only let ID-verified users transact. (A built-in “require this verification” step-up is on the roadmap.)

Who pays: identity verification is a one-time paid step for the user, and it’s portable — they verify once and carry it to every platform, so you get a verified user without running (or paying for) KYC per check. If you’d rather remove that friction, you can sponsoryour users’ verification (you cover the fee) — talk to us to enable it.