Aller au contenu
Bastide Connexion Créer un compte
Appuyez sur / pour chercher

Authentification unique (SSO) et SCIM

EnglishMarkdownv0.3.0

L'authentification unique permet aux membres d'une organisation d'entrer dans la console par le fournisseur d'identité de leur entreprise, et SCIM laisse l'annuaire de l'entreprise créer et désactiver leurs comptes. Cette page dit ce qui fonctionne aujourd'hui, ce qui manque encore, et à partir de quel palier la fonction est prévue.

Où en est la fonction

ÉlémentÉtat
Connexion à la console par un fournisseur OpenID ConnectServie : bouton « Se connecter avec l'authentification unique » de la page de connexion.
Provisionnement SCIM 2.0 des comptes (/scim/v2/Users)Servi.
Configuration du fournisseur et frappe du jeton SCIMPas encore disponible en libre-service : aucun écran, et l'opération sso.configure est déclarée mais pas servie (la route rend 404).
SAMLPas disponible. Il passera par un service séparé, jamais par du SAML écrit dans la plateforme.
Correspondance des groupes de l'annuaire vers les rôlesPas disponible.

La grille tarifaire range l'authentification unique et SCIM dans les paliers Standard, Pro et Souverain ; elles ne sont pas prévues au palier Découverte. Voir Facturation.

Attention. Cette page parle de l'entrée de vos équipes dans la console de Bastide. La connexion des utilisateurs de votre application par Google, Microsoft Entra ID, Keycloak et les autres fournisseurs est une autre fonction : voir Authentification.

Comment se passe une connexion

  1. Sur la page de connexion de la console, la personne choisit « Se connecter avec l'authentification unique » et saisit l'identifiant court (slug) de son organisation.
  2. La console l'envoie chez le fournisseur d'identité de l'organisation.
  3. Le fournisseur la renvoie sur https://console.bastide.app/connexion/sso, l'adresse de retour à enregistrer chez lui.
  4. La plateforme vérifie la réponse et ouvre une session de console, ou demande d'abord le second facteur.

Les règles qui protègent ce chemin :

  • Seul un compte provisionné par l'annuaire SCIM de l'organisation ouvre une session par ce chemin. Un fournisseur, même mal réglé, ne prend donc jamais le compte d'une adresse déjà inscrite ailleurs sur la plateforme.
  • À la première connexion, l'identifiant du fournisseur (sub) se lie au compte ; c'est ensuite lui qui désigne le compte. Une adresse renommée chez le fournisseur ne déplace pas l'identité.
  • Le second facteur de Bastide reste dû. Un compte qui en tient un le donne après le fournisseur, comme après un mot de passe. Voir Sécurité.
  • Un compte suspendu, par l'annuaire ou par l'exploitation, n'ouvre rien.

Ce que la plateforme vérifie

  • Flux du code d'autorisation avec **PKCE S256**, en client public : aucun secret de client n'est gardé.
  • Portées demandées : openid email profile.
  • Le paramètre state vit 10 minutes et ne sert qu'une fois.
  • Le jeton d'identité doit être signé en RS256 ou ES256 par une clé publiée par le fournisseur ; l'émetteur, l'audience, l'échéance et le nonce sont vérifiés. Tout autre algorithme est refusé.
  • L'adresse de l'émetteur est contrôlée comme une adresse sortante, et sa découverte OpenID Connect doit répondre : une configuration qui ne mène à aucun fournisseur est refusée d'emblée.

Tout fournisseur conforme à OpenID Connect avec découverte convient : Keycloak, Microsoft Entra ID, Okta, Google Workspace.

Les deux appels de la connexion

Pour un outil qui pilote la connexion lui-même, la console utilise deux routes de l'API, hors du catalogue des opérations :

curl -X POST https://api.bastide.app/v1/account/sso/start \
  -H "Content-Type: application/json" \
  -d '{ "organization": "mon-organisation" }'

La réponse porte authorizationUrl, où envoyer la personne, et expiresAt. Au retour, la page /connexion/sso poste le code et l'état reçus :

{ "code": "…", "state": "…" }

à POST /v1/account/sso/complete. La réponse est celle d'une connexion ordinaire : une session, ou le défi du second facteur.

SCIM : créer et désactiver les comptes depuis l'annuaire

L'annuaire de l'entreprise s'adresse à https://api.bastide.app/scim/v2/, avec un jeton porteur propre à l'organisation. Ce jeton n'ouvre que ces routes, et vit 90 jours au plus.

RouteEffet
GET /scim/v2/ServiceProviderConfigCe que le service accepte : PATCH et filtre oui (200 résultats au plus), ni lot, ni tri, ni changement de mot de passe.
GET /scim/v2/UsersLes comptes que cet annuaire a créés, filtrables.
POST /scim/v2/UsersCrée un compte. Une adresse qui a déjà un compte sur la plateforme est refusée (409).
GET, PUT, PATCH /scim/v2/Users/{id}Lit ou modifie un compte ; active: false le désactive.
DELETE /scim/v2/Users/{id}Désactive le compte, sans l'effacer : son historique reste attaché.

Une désactivation prend effet à la requête même : le compte est suspendu, ses sessions de console sont fermées, ses jetons personnels sont refusés tant qu'il l'est. Réactiver le compte ne lève que la suspension posée par l'annuaire.

Le provisionnement crée le compte ; il ne lui donne aucun rôle. Les rôles se donnent ensuite comme pour tout compte, par invitation (voir Organisations et membres).

Erreurs fréquentes

CodeStatutCe qui se passeQue faire
sso_indisponible404L'organisation n'a pas de connexion unique active, son fournisseur ne répond pas, ou l'identifiant saisi est inconnu. La réponse est la même dans les trois cas.Vérifiez l'identifiant court de l'organisation ; sinon, connectez-vous par mot de passe.
sso_refuse401Retour du fournisseur refusé : état échu ou déjà servi, jeton d'identité invalide, ou aucun compte actif provisionné par l'annuaire.Recommencez depuis la page de connexion ; si cela persiste, vérifiez que l'annuaire a bien créé votre compte.
trop_de_tentatives429Trop d'échecs depuis votre adresse IP.Attendez la durée indiquée par l'en-tête Retry-After.
(SCIM)401Jeton SCIM absent, inconnu, échu ou révoqué ; la réponse ne dit pas lequel.Remplacez le jeton dans l'annuaire.

Voir aussi : Sécurité, Organisations et membres, Journal d'audit, Authentification.

Signaler une erreur sur cette page