Aller au contenu
Usher IdentityUsher Identity

L’identité pour vos apps, sur des standards ouverts

Vous fait entrer.

Un seul compte. Toutes les portes.

Usher Identity connecte les utilisateurs à vos apps avec OpenID Connect et OAuth 2.1 : clés d’identification, codes, connexion sociale et organisations, chaque environnement restant isolé de tous les autres.

Commencer Lire la documentation

Gratuit pour commencer. Fonctionne aussi sur vos propres serveurs.

Le Lobby

Une page de connexion qui accueille au lieu d’interroger.

Le Lobby est la page de connexion qu’Usher Identity héberge pour votre app. Il indique toujours où va la personne, et il a le même aspect quelle que soit l’app qui l’y envoie : les utilisateurs apprennent ainsi à lui faire confiance.

En route vers
Thème
  • Nomme à chaque fois le produit vers lequel vous allez.
  • Clés d’identification, codes par e-mail et liens magiques, avec des mots de passe uniquement si vous le souhaitez.
  • La même page sereine, claire ou sombre, dans chaque produit.

Ceci est une copie fonctionnelle du Lobby. Elle s’exécute dans cette page, n’envoie rien et ne connecte personne.

Usher IdentityUsher IdentityEn route vers Acme Notes

Bon retour parmi nous.

Connectez-vous avec votre compte Usher Identity.

Première visite ?

Sécurisé par Usher Identity

Des standards, pas de dépendance

Parle les protocoles que votre stack connaît déjà.

Usher Identity est avant tout un fournisseur OpenID Connect. Utilisez notre SDK quand cela vous convient, ou n’importe quelle bibliothèque OIDC, dans n’importe quel langage. Si vous partez un jour, vos apps n’auront pas à changer leur façon de connecter les utilisateurs.

Jetons d’actualisation, consentement et portées inclus.
  • OIDC Core · Discovery

    OpenID Connect

    Un document de découverte par environnement, des jetons d’ID et userinfo. Toute bibliothèque cliente certifiée fonctionne.

  • S256 uniquement

    OAuth 2.1 avec PKCE

    Code d’autorisation avec PKCE pour chaque client, public ou confidentiel. Pas de flux implicite, pas de mot de passe envoyé au point de terminaison de jeton.

  • RS256 · ES256 · EdDSA

    JWKS et rotation des clés

    Chaque environnement signe avec ses propres clés, publiées à son jwks_uri. Effectuez leur rotation sans perturber les utilisateurs connectés.

  • RFC 7662 · RFC 7009

    Introspection et révocation

    Demandez si un jeton est toujours valide, ou révoquez-le sur-le-champ. Usher Identity vérifie ses propres sessions à chaque requête : mettre fin à l’une d’elles prend donc effet aussitôt.

  • Déconnexion depuis l’app et par canal arrière

    Déconnectez les utilisateurs depuis votre app, ou laissez Usher Identity prévenir chaque app dès qu’une session se termine, où que ce soit.

  • RFC 9449

    DPoP

    Liez les jetons à une clé que détient le client : un jeton volé ne sert alors à rien à lui seul.

  • WebAuthn

    Clés d’identification

    Prises en charge d’emblée, pas en option. Les utilisateurs se connectent avec leur empreinte, leur visage ou une clé de sécurité, et l’hameçonnage n’a aucune prise.

  • TOTP

    Apps d’authentification

    Des codes temporaires depuis n’importe quelle app d’authentification, avec des codes de secours. Rendez le second facteur facultatif ou obligatoire.

  • Liens magiques

    D’un simple toucher depuis la boîte de réception. Éphémères, à usage unique et liés à l’environnement qui les a envoyés.

  • Codes par e-mail

    Six chiffres, pour ceux qui se connectent sur un appareil et lisent leurs e-mails sur un autre.

  • Connexion sociale

    Google, GitHub, Microsoft et Apple. Un compte n’est associé qu’une fois son adresse e-mail vérifiée.

  • Organisations et équipes

    Membres, rôles et invitations pour les entreprises qui utilisent votre app.

  • Bientôt disponible

    SAML

    Authentification unique avec les fournisseurs d’identité professionnels de vos clients.

  • Bientôt disponible

    SCIM

    Provisionnement et déprovisionnement depuis les annuaires de vos clients.

Le déroulement d’une connexion

Cinq étapes, toutes standard.

Voici le flux de code d’autorisation d’OpenID Connect avec PKCE, celui que parle tout fournisseur d’identité sérieux. Faites défiler pour le suivre.

  1. 01

    Votre app envoie vos utilisateurs vers le Lobby.

    Quand quelqu’un choisit Continuer avec Usher Identity, votre app le redirige vers le point de terminaison d’autorisation de votre environnement, avec un défi PKCE et une valeur state qu’elle vérifiera plus tard.

    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

    Ils se connectent, à leur façon.

    Clé d’identification, code par e-mail, lien magique, compte social ou mot de passe : le Lobby ne propose que ce que votre environnement autorise, et indique toujours vers quelle app ils se dirigent.

    Usher IdentityUsher IdentityEn route vers Acme

    Bon retour parmi nous.

    Utiliser une clé d’identification
    Recevoir un code par e-mail
  3. 03

    Ils acceptent le partage.

    La première fois, les utilisateurs voient ce que votre app demande (leur profil, leur adresse e-mail, le maintien de leur connexion) et donnent leur accord une fois pour toutes.

    Acme souhaite :

    • Voir votre nom et votre photo
    • Voir votre adresse e-mail
    • Maintenir votre connexion
    AnnulerAutoriser
  4. 04

    Usher Identity renvoie un code.

    Le navigateur revient sur votre URI de redirection avec un code à usage unique valable cinq minutes, ainsi que le state que vous avez envoyé, que votre app vérifie.

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

    Votre app l’échange contre des jetons.

    Votre serveur envoie le code et le vérificateur PKCE au point de terminaison de jeton. En retour : un jeton d’ID qui indique qui ils sont, un jeton d’accès pour votre API, et un jeton d’actualisation pour qu’ils restent connectés.

    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
}

Isolé par conception

Chaque environnement est un bâtiment à part.

Vos environnements de production et de développement, comme ceux de tous les autres clients, ne partagent rien d’important. Une erreur dans l’un ne peut ni lire un autre, ni signer à sa place, ni s’y connecter.

Son propre schéma Postgres
Pas une colonne de locataire dans une table partagée : un schéma créé pour l’environnement, et rien d’autre dedans.
Ses propres clés de signature
Les jetons d’un environnement ne peuvent jamais être vérifiés avec les clés d’un autre.
Ses propres secrets scellés
Scellés avec la clé de données de l’environnement, elle-même enveloppée par une clé maîtresse.
Son propre hôte
Les émetteurs se trouvent sur un autre domaine que le site d’Usher et la Console, avec des cookies limités à leur hôte.

usheridentity.com

Le site, Usher Identity Console, les comptes Usher Identity

*.usherid.com

Un émetteur par environnement, sur un domaine distinct

Environnement

Les utilisateurs, les sessions et les jetons se trouvent dans un schéma créé pour cet environnement. Les requêtes s’exécutent sur ce schéma, jamais sur une table partagée avec une colonne de locataire.

Copier le secret client Google scellé de l’environnement de production Acme vers l’environnement de production Northwind.

Pour les développeurs

Votre première connexion, de trois façons.

Intégrez le SDK dès sa sortie, utilisez la bibliothèque OIDC à laquelle vous faites déjà confiance, ou commencez par lire le document de découverte. Au fond, c’est toujours le même protocole.

Démarrage rapide : Next.js Démarrage rapide : toute bibliothèque OIDC
app/layout.tsx · app/page.tsxDisponible avec le 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 />
}

Auto-hébergement

Vos serveurs, vos clés.

Utilisez Usher Identity en tant que service, ou exécutez la même plateforme sur vos propres serveurs, avec vos propres clés et votre propre base de données.

  • Docker

    Un seul fichier Compose : les apps, Postgres, Valkey, Caddy en frontal et le proxy de sortie. Les conteneurs s’exécutent sans nouveaux privilèges et avec leurs capacités Linux retirées.

  • Ubuntu

    Un simple serveur Ubuntu suffit. Caddy assure la terminaison TLS, et les secrets sont des fichiers remis aux conteneurs, jamais intégrés aux images.

  • Postgres

    Postgres contient tout, avec un schéma par environnement. Postgres et Valkey se trouvent sur un réseau sans route vers Internet.

Depuis un clone d’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

Le guide complet de l’auto-hébergement arrive bientôt. Les commandes ci-dessus en donnent les grandes lignes.

Faites entrer vos utilisateurs.

Créez un espace de travail et un projet : votre premier environnement arrive avec son propre émetteur, ses clés et son Lobby.

Commencer Suivre le guide de démarrage rapide

Une connexion, et bienvenue partout.