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'identite construite sur OAuth 2.0 qui permet aux utilisateurs de se connecter avec leur compte SendSeven. Lors de l'authentification, SendSeven emet un token ID JWT signe 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 role Admin ou Proprietaire

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

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

Etat vide des Applications OAuth dans les Parametres SendSeven montrant le bouton Creer une app

Formulaire des parametres generaux de creation 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

Selection des portees 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 difference entre OIDC et OAuth 2.0 ?

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

SendSeven prend-il en charge PKCE ?

Oui. PKCE (Proof Key for Code Exchange) est entierement supporte et recommande pour tous les types de clients, en particulier les apps mobiles et les SPAs. Il previent les attaques d'interception de code d'autorisation.

Quelles portees sont disponibles ?

Portees 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 duree de validite des tokens ?

Les tokens ID ont une duree de validite d'une heure. Les tokens d'acces expirent selon votre type de grant et la configuration du client. Verifiez toujours le claim exp dans le JWT.

Puis-je renouveler un token expire ?

Oui, si vous avez demande la portee 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 parametre tenant dans la requete d'autorisation pour diriger les utilisateurs vers une authentification specifique au tenant. L'OIDC de SendSeven peut emettre des tokens limites a votre espace de travail.