đŸ‡«đŸ‡· FranceConnect

Guide pour la solution d'authentifications de particuliers officielle des services publics numériques

Cette page est à destination des développeur.se.s implémentant la connexion usagers via FranceConnect (FC). On est ici dans le contexte d'un Fournisseur de Services (FS) dans la terminologie de FC.

Cette page vient en complément de la documentation officielle disponible sur https://partenaires.franceconnect.gouv.fr/documentation pour détailler quelques points précis uniquement. Ces infos sont tirées d'expériences passées sur RDV-Solidarités et Civils de la Défense, et d'échanges avec le support de FC.

Exemples d'implémentations

Nous vous encourageons Ă  parcourir le reste de cette page avant de regarder et vous inspirer des exemples de code, vous gagnerez du temps !

Démarches Simplifiées

Ruby On Rails + Devise + openid_connect

ImplĂ©mentĂ© pour la premiĂšre fois en 2016, code qui date un peu. Visible sur GitHub: https://github.com/betagouv/demarches-simplifiees.fr/​

Civils de La DĂ©fense

Ruby On Rails + Devise + omniauth_openid_connect

Pull Request de fevrier 2021 : https://github.com/betagouv/civilsdeladefense/pull/782​

RDV-Solidarités

Ruby On Rails + Devise + omniauth_openid_connect

Pull Request de fĂ©vrier 2021 https://github.com/betagouv/rdv-solidarites.fr/pull/752​

RĂ©conciliation

C'est le processus de fusion d'un compte FC avec un compte pré-existant dans le systÚme d'authentification de votre service

Identité pivot

L'identité pivot (IP) est définie par le 6-tuple suivant :

  • nom de naissance

  • prĂ©noms

  • sexe

  • date de naissance

  • lieu de naissance

  • pays de naissance

L'email et le numĂ©ro de tĂ©lĂ©phone ne font pas partie de l'IP, ce sont des moyens de contacts pouvant changer et ĂȘtre partagĂ©s entre usagers.

Un champ "SUB" est aussi envoyé, il contient un hash de l'IP, unique par fournisseur de services. Il semble que ce champ ne soit pas un identifiant unique de l'usager mais bien un hash des valeurs de l'IP, ce qui réduit légÚrement son utilité - il changera dans le rare cas d'un changement d'état civil d'un usager.

Algorithme de réconciliation automatique

Ces deux comparaisons doivent-ĂȘtre effectuĂ©es successivement pour rĂ©concilier des comptes sans intervention de l'usager :

  1. identité du champ SUB

  2. identité des 6 champs de l'IP

Contacté à ce sujet, le support de FranceConnect ne donne pas de bonnes pratiques sur la comparaison de l'IP avec les infos de votre systÚme d'authentification. Vous pouvez donc décider librement de faire des comparaisons sensibles ou non à la casse, aux symboles de ponctuation, aux espaces etc...

On peut malgrĂ©s tout trouver un exemple d'algorithme de rĂ©conciliation en NodeJS sur un de leur dĂ©pĂŽt de code sur github : https://github.com/france-connect/data-provider-example/blob/b767251ce458b6f01510cbc16ba17e205864422c/src/services.js#L133-L183​

Il ne faut donc pas faire de rĂ©conciliation automatique sur base de l'email ou du numĂ©ro de tĂ©lĂ©phone, mĂȘme si ce sont des identifiants uniques dans le systĂšme d'authentification prĂ©-existant de votre systĂšme. Si un usager a utilisĂ© un email diffĂ©rent pour AmĂ©li et pour les impĂŽts, l'adresse envoyĂ©e par FC sera diffĂ©rente. Des membres d'une famille peuvent aussi partager un compte email. C'est pour ces raisons qu'il est interdit de faire la rĂ©conciliation automatiquement sur base de l'email seul

Malgré cette remarque validée par le support de FC, cette pratique est tolérée. Par exemple Démarches Simplifiées fait une réconciliation automatique sur base de l'email seul (voir le code ici). Le support de FC nous dit :

Ce process de rĂ©conciliation est de la responsabilitĂ© du fournisseur de service, c’est lui qui prend en charge son risque et les erreurs potentielles de rĂ©conciliation rĂ©alisĂ©es sur trop peu de donnĂ©es

RĂ©conciliation manuelle

Cette procédure implique une intervention de l'usager pour prouver son identité, et vient en paliatif si la procédure automatique n'a pas fonctionnée.

Elle peut-ĂȘtre utile dans le cas oĂč un usager se connecte avec FC avec un email dĂ©jĂ  existant dans le systĂšme d'authentification de votre produit, mais que la rĂ©conciliation automatique n'a pas associĂ© les comptes. C'est aussi valable pour les numĂ©ros de tĂ©lĂ©phones. La majoritĂ© des systĂšmes d'authentification supposent une unicitĂ© de ces champs et vous ne pourrez donc pas crĂ©er de nouveau compte.

Il vous faudra alors demander Ă  l'usager un "secret" comme un numĂ©ro de dossier, ou un autre identifiant unique auquel seul lui a accĂšs pour valider son identitĂ© et procĂ©der Ă  la rĂ©conciliation des comptes. S'il n'y a pas de secret Ă©vident; le mot de passe peut-ĂȘtre demandĂ©. Il faut nĂ©cessairement fournir une fonctionnalitĂ© de rĂ©cupĂ©ration de mot de passe dans ce cas.

L'intĂ©rĂȘt de FC versus une connexion classique, dans le cas d'une rĂ©conciliation manuelle via mot des passe est limitĂ©, mais pas nul, cela permet tout de mĂȘme de rapprocher les comptes et rĂ©cupĂ©rer les informations certifiĂ©es de FC.

Présence de l'email

On peut considérer qu'un email est toujours retourné dans les informations FC.

Certains éléments de la documentation peuvent porter à penser le contraire, par exemple :

Dans le cadre de l'interopérabilité eIDAS, l'e-mail ne sera pas envoyé la majorité du temps car non obligatoire

Cette remarque signifie en fait que l'email ne sera pas envoyé dans certains cas; mais qui n'ont pas l'air de nous concernet. eIDAS est un protocole d'échange d'infos officiel européen.

Une autre chose pouvant porter à confusion est la présence de comptes de test (cf ce fichier csv) soient explicitement des comptes sans email. Vous pouvez ignorer ces comptes et ne pas les tester.

Rendre les champs de l'IP non modifiables

Une fois un usager connectĂ© via FC, les champs de son IP doivent devenir non-modifiables. Le raisonnement est que ces infos ont Ă©tĂ© validĂ©es par le FI et n'ont donc aucune raison d'ĂȘtre modifiĂ©es.

C'est le cas peu importe le mode de connexion ultĂ©rieur de cette personne. C'est Ă  dire que mĂȘme si le compte a Ă©tĂ© rĂ©conciliĂ©, et que l'usager se connecte par la suite avec son mot de passe, il faut que les champs restent non-Ă©ditables.

C'est aussi le cas pour les Ă©ventuels agents publics ayant accĂšs en Ă©criture aux comptes usagers de votre DB, par exemple depuis une vue backoffice.

Notez aussi que parmi les champs de l'IP est le nom de naissance, mais pas le nom d'usage qui lui peut rester modifiable dans votre service.

Il faut donc stocker l'information qu'un usager s'est déjà connecté une fois via FC de maniÚre durable dans votre BDD

Contacté à ce sujet, le support de FranceConnect ne fournit pas de contenus types à présenter à l'usager pour expliquer cette interdiction de modification. Il faut indiquer aux usagers que s'ils veulent les modifier, il faut qu'ils modifient leur état civil directement.

Astuces

Lorsque votre tentative de connexion Ă  un FI de test Ă©choue avec une erreur cĂŽtĂ© FC, vous pouvez vous retrouver bloquĂ© et ne plus rĂ©ussir Ă  vous dĂ©connecter de ce compte. Pour y remĂ©dier, il faut soit vider le cookie du domaine du fournisseur d'identitĂ© (pas toujours Ă©vident Ă  trouver, cherchez franceconnect ou fcp dans la liste de vos cookies), ou bien rouvrir une fenĂȘtre de navigation privĂ©e Ă  chaque fois