Login social (Google, Microsoft, OIDC générique)

Fédération entrante avec Obexal comme relying party : connexions par organisation, liaison de compte sur e-mail vérifié, aucun jeton externe conservé, la MFA s'applique toujours.

Le login social délègue l'authentification primaire à un fournisseur OpenID Connect externe (« Se connecter avec... »), puis ouvre une session Obexal ordinaire. Le flux Authorization Code + PKCE se déroule entièrement côté serveur ; le navigateur n'effectue que des navigations top-level.

Les fournisseurs pris en charge

Identifiant	Fournisseur	Notes
`google`	Google	OIDC standard, claim `email_verified` exigé
`microsoft`	Microsoft Entra ID	Entra n'émet pas de claim `email_verified` ; l'e-mail affirmé est considéré vérifié (Entra ne renvoie que des adresses qu'il contrôle)
`oidc`	OIDC générique	Tout IdP conforme à la spécification, y compris un IdP européen auto-hébergé : l'option souveraine recommandée

Note

Les déploiements auto-hébergés peuvent poser SOCIAL_SOVEREIGN_ONLY=true : Google et Microsoft ne sont alors pas montés du tout, même configurés, et il ne reste que le connecteur OIDC générique et le SAML d'entreprise. Voir la configuration.

Configurer une connexion pour votre organisation

Les connexions se configurent par organisation et surchargent le fournisseur global de même identifiant (ou en ajoutent un qui n'est pas activé globalement). Enregistrez cette URI de redirection chez votre fournisseur : https://accounts.obexal.com/v1/auth/social/{provider}/callback (votre domaine de connexion personnalisé remplace accounts.obexal.com si vous en utilisez un).

curl -sS -X POST https://accounts.obexal.com/v1/admin/social/connections \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "provider": "oidc",
    "displayName": "IdP interne",
    "issuer": "https://idp.example.eu",
    "clientId": "obexal-rp",
    "clientSecret": "'$IDP_CLIENT_SECRET'",
    "scopes": ["openid", "email", "profile"],
    "emailTrust": 0
  }'
# 204

emailTrust : 0 exige le claim email_verified (politique par défaut), 1 fait confiance à l'e-mail affirmé par le fournisseur (nécessaire pour Microsoft Entra).
Le clientSecret est chiffré au repos. S'il ne peut plus être déchiffré, la connexion devient indisponible (fail-closed) plutôt que de se replier sur une autre configuration.
GET /v1/admin/social/connections liste les connexions (identifiants connus : google, microsoft, oidc) ; DELETE /v1/admin/social/connections/{provider} en supprime une.

Le déroulement de la connexion

# 1. Lister les fournisseurs activés pour l'organisation (l'UI de connexion affiche les boutons).
curl -sS https://accounts.obexal.com/v1/auth/social/providers
# 200 -> {"providers":[{"id":"google","displayName":"Google"},{"id":"oidc","displayName":"IdP interne"}]}

# 2. Start : le navigateur est redirigé (302) vers le fournisseur.
#    redirect_uri est la cible post-connexion, validée contre les origines autorisées.
curl -sSi "https://accounts.obexal.com/v1/auth/social/google/start?redirect_uri=https://portal.example.eu/"
# 302 Location: https://accounts.google.com/o/oauth2/v2/auth?...&code_challenge_method=S256&state=...

# 3. Callback (appelé par le fournisseur) : GET /v1/auth/social/{provider}/callback
#    Succès -> 302 vers redirect_uri avec le cookie de session posé.
#    Échec -> 302 vers redirect_uri?error=social_*  (aucune session).

Entre start et callback, le flux est protégé par un state à usage unique stocké haché côté serveur (TTL de 10 minutes), un code_verifier pour PKCE (S256), un nonce lié à l'id_token, et un cookie de liaison obexal_social_state qui rattache le callback au navigateur qui a initié le flux. Au callback, le serveur échange le code et valide l'id_token : signature RS256 contre le JWKS du fournisseur, iss, aud, exp et nonce.

La résolution du compte

Le compte est résolu selon une politique stricte d'e-mail vérifié :

L'identité (provider, subject) est déjà liée : connexion directe.
Première fois pour cette identité : le fournisseur doit affirmer un e-mail vérifié, sinon le flux échoue avec error=social_email_unverified. Aucun compte n'est jamais créé ni lié sur une adresse non vérifiée.
Un compte local existe avec cet e-mail vérifié : l'identité y est liée automatiquement.
Aucun compte n'existe : un compte est provisionné, avec l'e-mail déjà marqué vérifié.

Chaque utilisateur peut consulter et retirer ses identités liées : GET /v1/auth/identities et DELETE /v1/auth/identities/{provider}. La déliaison est refusée (409 last_credential) si elle retirait la dernière méthode de connexion du compte.

La MFA s'applique après la fédération

Le login social est un facteur primaire, exactement comme le mot de passe : si le compte résolu a un facteur MFA actif, aucune session n'est ouverte au callback. Le navigateur est redirigé vers l'écran MFA de l'interface de connexion avec un token de défi à usage unique, et la session n'existe qu'une fois le second facteur validé. Voir le point de passage MFA.

Ce qu'Obexal conserve

Obexal ne persiste que le lien d'identité : (provider, subject) plus l'e-mail, rattaché à votre organisation. Aucun access token, refresh token ou id_token externe n'est jamais stocké : l'id_token est vérifié en mémoire pendant le callback puis abandonné. La preuve d'identité est la vérification elle-même, pas un credential sauvegardé.

Limites, en toute honnêteté

L'id_token amont doit être signé en RS256. Tout autre algorithme (ES256, HS256, ...) est explicitement refusé, en défense contre la confusion d'algorithmes, et seules les clés RSA sont lues dans le JWKS du fournisseur. Un IdP qui ne signe qu'en courbes elliptiques ne peut pas être connecté aujourd'hui.
Le flux passe par le navigateur (navigations GET) ; il n'existe pas de variante du login social en API pure.