Hosted Login (Universal Login)

Toute application qui authentifie des utilisateurs doit décider où vit le formulaire de login. Il y a trois approches fondamentales et le choix a de profondes implications de sécurité.

L’application rend son propre formulaire de login et collecte les credentials directement. Le problème : le code JavaScript de ton application peut lire le formulaire de login, intercepter les touches pressées et accéder aux credentials.

Les credentials sont saisies sur une origine différente — celle contrôlée par l’identity provider. Le JavaScript de ton application ne peut pas lire les champs du formulaire, intercepter les touches pressées ou accéder aux credentials de quelque manière que ce soit. La politique same-origin du browser applique cette frontière automatiquement.

Risque	Login Intégré	Login Hébergé
XSS vole les credentials	Oui — ton JS peut lire le champ mot de passe	Non — origine différente, ton JS ne peut pas y accéder
Script tiers lit les credentials	Oui	Non — les scripts tiers sur ton origine ne peuvent pas atteindre la page auth
Phishing des credentials via manipulation DOM	Oui	Non — la page de login est sur le domaine de l’IdP
Enforcement MFA	Tu dois l’implémenter	L’IdP le gère de manière transparente
Périmètre d’audit de conformité	Toute ton application	Seulement les pages de login de l’IdP

Le Hosted Login est l’approche recommandée par l’OAuth 2.0 Security Best Current Practice (RFC 6819). Auth0 l’appelle “Universal Login,” Okta l’appelle “Okta-hosted Sign-In,” et Auris l’appelle “Hosted Login.” Le principe de sécurité est le même : ne laisse jamais ton application toucher les credentials brutes.

Comment ça Fonctionne : Le Flux Complet

Auris Hosted Login implémente le flux OAuth2 Authorization Code avec PKCE (RFC 7636). Le flux :

Ton app génère un code verifier et un code challenge PKCE
Le browser est redirigé vers l’endpoint /api/oauth/authorize d’Auris avec le code challenge
Auris crée une OAuthSession pour tracker la progression
L’utilisateur est redirigé vers la page de login hébergée d’Auris
L’utilisateur saisit ses credentials (email/mot de passe, magic link, social, etc.)
Si requis, l’écran MFA est présenté
Auris émet un authorization code à usage unique (5 minutes)
Le browser est redirigé vers le redirect_uri de ton app avec le code
Ton app valide le state (protection CSRF) et échange le code contre des tokens
Auris vérifie le code challenge PKCE et émet les tokens

PKCE S256 : Pourquoi C’est Important

PKCE (Proof Key for Code Exchange) prévient les attaques d’interception de l’authorization code.

Si un attaquant intercepte l’authorization code dans l’URL de redirection, il ne peut pas l’échanger. Pour échanger le code, il a besoin du code_verifier — qui n’a jamais été transmis par la barre URL du browser. Il était stocké dans la mémoire du client et envoyé directement à l’endpoint token via HTTPS.

Auris applique PKCE S256 à tous les flux authorization code. La méthode de challenge plain est rejetée. Il n’existe pas de configuration pour désactiver PKCE — il est toujours requis.

Gestion des Sessions

Auris utilise deux modèles côté serveur pour gérer le flux hosted login :

OAuthSession

Créée quand l’utilisateur arrive à l’endpoint authorize. Stockée dans la base de données et identifiée par un cookie httpOnly.

Champ	Description
`sessionToken`	Identifiant unique (défini comme cookie httpOnly, Secure, SameSite=Lax)
`clientId`	L’application qui demande l’authentification
`redirectUri`	Où rediriger après l’authentification
`codeChallenge`	Code challenge PKCE (S256)
`state`	Valeur state CSRF du client
`scope`	Scopes OAuth demandés
`TTL`	30 minutes (la session expire si l’utilisateur ne complète pas le login)

AuthorizationCode

Créé après une authentification réussie.

Champ	Description
`code`	Authorization code unique
`clientId`	Doit correspondre au `client_id` de la requête token
`redirectUri`	Doit correspondre exactement au `redirect_uri` de la requête token
`codeChallenge`	Stocké pour la vérification PKCE lors de l’échange token
`TTL`	5 minutes
`usedAt`	Défini atomiquement à la première utilisation (enforcement à usage unique)

Chaque tentative de login passe par un pipeline de vérifications de sécurité dans cette séquence :

Rate limiting : Limite de 10 tentatives par IP toutes les 15 minutes
Compte bloqué : Si le compte est bloqué, refus immédiat
Vérification des credentials : Email + mot de passe vérifié dans Keycloak
Détection des accès suspects : IP/pays inconnu, nouvel appareil, heure inhabituelle
Risk scoring adaptatif : Score de 0 à 100 basé sur des signaux comportementaux
Évaluation de la policy MFA : Déclenchement MFA si requis par la policy ou le score de risque
Actions Engine : Hooks personnalisés pre_login et post_login
Émission des tokens : Génération de l’access token, refresh token et ID token

Protection Brute Force

Métrique	Seuil	Action
Tentatives de login	10 en 15 min (par IP)	Blocage temporaire 15 min
Tentatives échouées	5 consécutives (par utilisateur)	Blocage du compte, email de notification
Trafic anormal	Détecté par analyse IP	Rate limiting adaptatif

Domaines Personnalisés

Quand un domaine personnalisé est configuré, la page de login hébergée est servie depuis ce domaine. Le pipeline de sécurité est identique. Les certificats SSL sont gérés automatiquement via Let’s Encrypt.

La page de login hébergée reflète automatiquement :

Le logo téléchargé dans les paramètres de branding
La couleur primaire de la marque
Le nom de l’organisation
Les fournisseurs de login social configurés

Implémentation avec le SDK


import { AurisClient } from '@auris/js'
 
const auris = new AurisClient({
  domain: 'api.altovar.net',
  clientId: 'votre-client-id',
  redirectUri: 'https://app.votredomaine.com/callback',
})
 
// Démarre le login
await auris.loginWithRedirect()
 
// Gère le callback
const { user } = await auris.handleRedirectCallback()

Le SDK gère automatiquement la génération PKCE, le stockage, la validation du state et l’échange du code.

Concepts Associés

OAuth 2.0 & OIDC — Les protocoles sous-jacents
Flux PKCE — Guide technique détaillé du flux PKCE
Sessions — Comment les sessions sont créées et gérées après le login
Guide Hosted Login — Intègre le login hébergé dans ton application
Branding — Personnalise l’apparence de la page de login

Hosted Login (Universal Login)

Le Problème : Où Doit Vivre le Formulaire de Login ?

Login Intégré (l’approche risquée)

Login Hébergé (l’approche sécurisée)