Connexion avec SendSeven (OIDC SSO)

Permettez à vos utilisateurs de s'authentifier avec leur compte SendSeven en utilisant OpenID Connect. Implémentez 'Connexion avec SendSeven' dans votre application pour une authentification unique transparente.

Nom d'affichage et avatar de l'utilisateur

Active les tokens de rafraîchissement pour les sessions de longue durée

Identifiant unique de l'utilisateur (User ID)

Nom d'affichage complet de l'utilisateur

URL vers la photo de profil de l'utilisateur

Nom d'affichage montré aux utilisateurs pendant le consentement

Application web, SPA, ou application native

Après l'enregistrement, vous recevrez votre Client ID et Client Secret.

Redirigez l'utilisateur vers l'URL d'autorisation avec scope=openid profile email

L'utilisateur s'authentifie avec SendSeven et accorde le consentement

L'utilisateur est redirigé vers votre URL de callback avec le code d'autorisation

Échangez le code contre des tokens (access_token + id_token)

Vérifiez la signature de id_token en utilisant JWKS

Extrayez les claims utilisateur depuis id_token ou appelez l'endpoint /userinfo

(émetteur) doit être https://api.sendseven.com

(audience) doit contenir votre Client ID

doit correspondre à celui que vous avez envoyé (si utilisé)

Assurez-vous que l'URI de redirection correspond exactement à celui enregistré avec votre application OAuth

Vérifiez les slashes finales ou les paramètres de requête

Vérifiez que l'URI utilise HTTPS (pas HTTP)

Vérifiez que votre Client ID est correct

Vérifiez que le Client Secret est envoyé correctement (encodé URL)

Assurez-vous que l'application OAuth est toujours active

Assurez-vous de récupérer le dernier JWKS (les clés tournent périodiquement)

Vérifiez que l'URL de l'émetteur correspond exactement

Confirmez que votre Client ID est dans le claim audience

OpenID Connect (OIDC) 1.0 est une couche d'identité construite sur OAuth 2.0 qui permet aux utilisateurs de se connecter avec leur compte SendSeven. Lors de l'authentification, SendSeven émet un token ID JWT signé contenant les claims utilisateur (email, profil, identifiant unique). Votre application valide la signature du token et extrait les informations utilisateur sans jamais manipuler de mots de passe. Cela permet des flux de connexion transparents "Se connecter avec SendSeven", le partage d'espaces de travail et l'authentification multi-tenant.

Un compte SendSeven avec le rôle Admin ou Propriétaire

Une URL de callback HTTPS dans votre application (requise pour la production)

Une bibliothèque client OpenID Connect pour votre plateforme (par ex. passport-openidconnect, Authlib, oidc-client-ts)

État vide des Applications OAuth dans les Paramètres SendSeven montrant le bouton Créer une app

Formulaire des paramètres généraux de création d'app OAuth avec les champs nom, description, URL de page d'accueil et URL de logo

Onglet de configuration des URIs de redirection pour l'app OAuth dans SendSeven avec les champs d'URL de callback

Sélection des portées de l'app OAuth avec OpenID Connect, Profile, Email et permissions API dans SendSeven

  1. Accéder aux paramètres SSO
  2. Configurer votre fournisseur d'identité
  3. Saisir les identifiants OIDC dans SendSeven
  4. Mapper les attributs utilisateur
  5. Tester la connexion SSO
  6. Activer le SSO pour votre organisation

FAQ

Quelle est la différence entre OIDC et OAuth 2.0 ?

OAuth 2.0 est un protocole d'autorisation (accorde l'accès aux ressources), tandis qu'OpenID Connect 1.0 est un protocole d'authentification construit sur OAuth 2.0 (fournit l'identité via des tokens ID). SendSeven prend en charge les deux.

SendSeven prend-il en charge PKCE ?

Oui. PKCE (Proof Key for Code Exchange) est entièrement supporté et recommandé pour tous les types de clients, en particulier les apps mobiles et les SPAs. Il prévient les attaques d'interception de code d'autorisation.

Quelles portées sont disponibles ?

Portées standard : openid (requis), profile, email, offline_access. SendSeven renvoie les claims utilisateur comme sub (identifiant unique), email, name, picture, email_verified et updated_at dans les tokens ID.

Quelle est la durée de validité des tokens ?

Les tokens ID ont une durée de validité d'une heure. Les tokens d'accès expirent selon votre type de grant et la configuration du client. Vérifiez toujours le claim exp dans le JWT.

Puis-je renouveler un token expiré ?

Oui, si vous avez demandé la portée offline_access lors de l'autorisation, vous recevrez un refresh_token. Envoyez-le via POST au endpoint /token pour obtenir un nouveau access_token et id_token.

Quels claims utilisateur SendSeven renvoie-t-il ?

Les tokens ID incluent : sub (identifiant utilisateur unique), email, email_verified, name, picture, locale, updated_at, et les claims JWT standard (iss, aud, exp, iat, nonce).

Comment prendre en charge le SSO multi-tenant ?

Utilisez le paramètre tenant dans la requête d'autorisation pour diriger les utilisateurs vers une authentification spécifique au tenant. L'OIDC de SendSeven peut émettre des tokens limités à votre espace de travail.