Zum Inhalt springen
Usher IdentityUsher Identity

Identität für deine Apps, auf offenen Standards

Bittet dich herein.

Ein Konto. Jede Tür.

Usher Identity meldet Menschen mit OpenID Connect und OAuth 2.1 bei deinen Apps an: mit Passkeys, Codes, Social Login und Organisationen – und jede Umgebung bleibt von jeder anderen getrennt.

Jetzt loslegen Zur Dokumentation

Kostenlos starten. Läuft auch auf deinen eigenen Servern.

Die Lobby

Eine Anmeldeseite, die willkommen heißt, statt zu verhören.

Die Lobby ist die Anmeldeseite, die Usher Identity für deine App bereitstellt. Sie zeigt immer, wohin es gerade geht, und sieht gleich aus, egal welche App jemanden hergeschickt hat – so lernen Menschen, ihr zu vertrauen.

Weiter zu
Design
  • Nennt jedes Mal das Produkt, zu dem es weitergeht.
  • Passkeys, Codes per E-Mail und Magic Links – Passwörter nur, wenn du sie willst.
  • Dieselbe ruhige Seite, hell oder dunkel, in jedem Produkt.

Das ist eine funktionierende Kopie der Lobby. Sie läuft auf dieser Seite, verschickt nichts und meldet niemanden an.

Usher IdentityUsher IdentityWeiter zu Acme Notes

Willkommen zurück.

Melde dich mit deinem Konto bei Usher Identity an.

Neu hier?

Geschützt durch Usher Identity

Standards statt Lock-in

Spricht die Protokolle, die dein Stack schon kennt.

Usher Identity ist in erster Linie ein OpenID-Connect-Provider. Nutze unser SDK, wenn es dir passt, oder jede beliebige OIDC-Bibliothek in jeder Sprache. Und solltest du einmal wechseln, müssen deine Apps nichts daran ändern, wie sie Menschen anmelden.

Refresh-Tokens, Einwilligung und Scopes inklusive.
  • OIDC Core · Discovery

    OpenID Connect

    Ein Discovery-Dokument pro Umgebung, ID-Tokens und Userinfo. Jede zertifizierte Client-Bibliothek funktioniert.

  • Nur S256

    OAuth 2.1 mit PKCE

    Autorisierungscode mit PKCE für jeden Client, ob öffentlich oder vertraulich. Kein Implicit Flow, keine Passwörter am Token-Endpunkt.

  • RS256 · ES256 · EdDSA

    JWKS und Schlüsselrotation

    Jede Umgebung signiert mit eigenen Schlüsseln, veröffentlicht unter ihrer jwks_uri. Rotiere sie, ohne dass angemeldete Nutzer etwas davon merken.

  • RFC 7662 · RFC 7009

    Introspection und Widerruf

    Frag nach, ob ein Token noch gültig ist, oder beende es sofort. Usher Identity prüft bei jeder Anfrage seine eigenen Sitzungen, deshalb wirkt das Beenden einer Sitzung unmittelbar.

  • RP-initiierter und Back-Channel-Logout

    Melde Nutzer aus deiner App heraus ab – oder lass Usher Identity jeder App Bescheid sagen, sobald irgendwo eine Sitzung endet.

  • RFC 9449

    DPoP

    Binde Tokens an einen Schlüssel, den der Client besitzt. Ein gestohlenes Token allein nützt dann niemandem.

  • WebAuthn

    Passkeys

    Von Anfang an dabei, kein Zusatz. Menschen melden sich mit Fingerabdruck, Gesicht oder Sicherheitsschlüssel an – und für Phishing gibt es nichts zu holen.

  • TOTP

    Authenticator-Apps

    Zeitbasierte Codes aus jeder Authenticator-App, mit Backup-Codes. Mach einen zweiten Faktor optional oder verpflichtend.

  • Magic Links

    Ein Tippen im Posteingang genügt. Kurzlebig, nur einmal verwendbar und an die Umgebung gebunden, die sie verschickt hat.

  • Codes per E-Mail

    Sechs Ziffern – für alle, die sich auf einem Gerät anmelden und ihre E-Mails auf einem anderen lesen.

  • Social Login

    Google, GitHub, Microsoft und Apple. Ein Konto wird erst verknüpft, wenn seine E-Mail-Adresse bestätigt ist.

  • Organisationen und Teams

    Mitglieder, Rollen und Einladungen für die Unternehmen, die deine App nutzen.

  • Demnächst

    SAML

    Single Sign-on über die Identity Provider, mit denen deine Kunden ihre Belegschaft verwalten.

  • Demnächst

    SCIM

    Konten anlegen und wieder entfernen, direkt aus den Verzeichnissen deiner Kunden.

So läuft eine Anmeldung ab

Fünf Schritte, jeder davon Standard.

Das ist der Autorisierungscode-Flow von OpenID Connect mit PKCE – derselbe Flow, den jeder ernstzunehmende Identity Provider spricht. Scroll einfach hindurch.

  1. 01

    Deine App schickt Nutzer zur Lobby.

    Wählt jemand „Mit Usher Identity fortfahren“, leitet deine App die Person zum Autorisierungsendpunkt deiner Umgebung weiter – mit einer PKCE-Challenge und einem State-Wert, den sie später prüft.

    GET acme.usherid.com/api/auth/oauth2/authorize
  ?response_type=code
  &client_id=acme_web
  &redirect_uri=https://app.acme.example/callback
  &scope=openid profile email offline_access
  &state=k3Jx…
  &code_challenge=E9Mel…cM
  &code_challenge_method=S256
  2. 02

    Sie melden sich an, ganz wie sie möchten.

    Ein Passkey, ein Code per E-Mail, ein Magic Link, Social Login oder ein Passwort: Die Lobby bietet nur an, was deine Umgebung erlaubt, und zeigt immer, zu welcher App es weitergeht.

    Usher IdentityUsher IdentityWeiter zu Acme

    Willkommen zurück.

    Passkey verwenden
    Code per E-Mail senden
  3. 03

    Sie stimmen der Freigabe zu.

    Beim ersten Mal sehen sie, worum deine App bittet (ihr Profil, ihre E-Mail-Adresse, angemeldet bleiben), und stimmen einmal zu.

    Acme möchte:

    • Deinen Namen und dein Bild sehen
    • Deine E-Mail-Adresse sehen
    • Dich angemeldet halten
    AbbrechenErlauben
  4. 04

    Usher Identity gibt einen Code zurück.

    Der Browser kehrt zu deiner Redirect-URI zurück – mit einem einmal verwendbaren Code, der fünf Minuten gilt, und dem State, den du mitgeschickt hast und den deine App prüft.

    302 Found
Location: https://app.acme.example/callback
  ?code=SplxlOBeZQQYbYS6WxSbIA
  &state=k3Jx…
  5. 05

    Deine App tauscht ihn gegen Tokens.

    Dein Server sendet den Code und den PKCE-Verifier an den Token-Endpunkt. Zurück kommen ein ID-Token, das sagt, wer die Person ist, ein Access-Token für deine API und ein Refresh-Token, damit sie angemeldet bleibt.

    POST acme.usherid.com/api/auth/oauth2/token
  grant_type=authorization_code&code=Splx…
  &code_verifier=dBjftJeZ4CVP…

{
  "token_type": "Bearer",
  "access_token": "eyJhbGciOiJSUzI1NiIs…",
  "id_token": "eyJhbGciOiJSUzI1NiIs…",
  "refresh_token": "8xLOxBtZp8…",
  "expires_in": 600
}

Isolation von Grund auf

Jede Umgebung ist ein eigenes Gebäude.

Deine Produktions- und Entwicklungsumgebungen – und die aller anderen Kunden – teilen nichts, worauf es ankommt. Ein Fehler in der einen kann in keiner anderen Daten lesen, etwas signieren oder jemanden anmelden.

Ein eigenes Postgres-Schema
Keine Mandantenspalte in einer gemeinsamen Tabelle, sondern ein Schema, das eigens für die Umgebung angelegt ist – und sonst nichts enthält.
Eigene Signaturschlüssel
Tokens aus einer Umgebung lassen sich nie mit den Schlüsseln einer anderen verifizieren.
Eigene versiegelte Secrets
Versiegelt mit dem eigenen Datenschlüssel der Umgebung, der seinerseits mit einem Hauptschlüssel verschlüsselt ist.
Ein eigener Host
Issuer liegen auf einer anderen Domain als Ushers Website und Console, mit Host-only-Cookies.

usheridentity.com

Die Website, Usher Identity Console, Konten bei Usher Identity

*.usherid.com

Ein Issuer pro Umgebung, auf einer eigenen Domain

Umgebung

Nutzer, Sitzungen und Tokens liegen in einem Schema, das eigens für diese Umgebung angelegt ist. Abfragen laufen gegen dieses Schema, nie gegen eine gemeinsame Tabelle mit Mandantenspalte.

Kopiere das versiegelte Google-Client-Secret aus der Produktionsumgebung von Acme in die Produktionsumgebung von Northwind.

Für Entwickler

Deine erste Anmeldung, auf drei Wegen.

Bau das SDK ein, sobald es da ist, nutze die OIDC-Bibliothek, der du schon vertraust, oder fang mit dem Discovery-Dokument an. Darunter steckt immer dasselbe Protokoll.

Schnellstart: Next.js Schnellstart: jede OIDC-Bibliothek
app/layout.tsx · app/page.tsxKommt mit dem SDK
// app/layout.tsx
import { UsherProvider } from '@usher/nextjs'

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <UsherProvider>{children}</UsherProvider>
      </body>
    </html>
  )
}

// app/page.tsx
import { SignIn, UserButton, currentUser } from '@usher/nextjs'

export default async function Page() {
  const user = await currentUser()
  return user ? <UserButton /> : <SignIn />
}

Selbst betreiben

Deine Server, deine Schlüssel.

Nutze Usher Identity als Dienst oder betreibe dieselbe Plattform auf deinen eigenen Servern, mit deinen eigenen Schlüsseln und deiner eigenen Datenbank.

  • Docker

    Eine Compose-Datei: die Apps, Postgres, Valkey, der Caddy-Edge und der Egress-Proxy. Die Container laufen ohne neue Privilegien und mit entzogenen Capabilities.

  • Ubuntu

    Ein einfacher Ubuntu-Server genügt. Caddy terminiert TLS, und Secrets werden den Containern als Dateien übergeben, nie in Images eingebaut.

  • Postgres

    Postgres hält alles, ein Schema pro Umgebung. Postgres und Valkey liegen in einem Netzwerk ohne Route ins Internet.

In einem Checkout von Usher Identity
# on an Ubuntu server with Docker Engine and the Compose plugin
bash infra/scripts/setup-env.sh --prod \
  --domain usher.example --tenant-domain usherid.example

docker compose -f compose.yaml -f compose.prod.yaml \
  --profile core --profile apps --profile edge up -d --wait

pnpm db:migrate   # applies the database migrations

Die vollständige Anleitung zum Selbstbetrieb ist unterwegs. Die Befehle oben zeigen schon, wie sie aussehen wird.

Bitte deine Nutzer herein.

Erstelle einen Workspace und ein Projekt – deine erste Umgebung bringt ihren eigenen Issuer, eigene Schlüssel und eine eigene Lobby mit.

Jetzt loslegen Zum Schnellstart

Einmal anmelden. Überall willkommen.