Introduction à la notion de fournisseur de données
Au sens OpenID un fournisseur de données (FD) correspond à un serveur de ressources (RS).
Le fournisseur de données se distingue du fournisseur de service (FS) par le fait qu'il ne prend pas en charge la cinématique d'authentification. En effet, il ne retourne les informations demandées uniquement sur présentation d'un access token valide émis par Pro Santé Connect.
Un FD offre, aux FS, un service spécifique d'enrichissement de la donnée issue du UserInfo. La communication entre un FS et un FD se base sur la norme Oauth.
Le FS va envoyer une demande au FD accompagnée de l'access token du demandeur qu'il aura authentifié.
- Le FD va vérifier la validité de l'access token envoyé par le FS par introspection et récupérer l'identité du demandeur
- Le FD va utiliser l'access token envoyé par le FS pour interroger le UserInfo si nécessaire dans la limite des scopes contenus dans l'AT obtenus par le FS.
Diagramme de flux
Devenir un fournisseur de données
Comme les FS, le FD doit s'authentifier auprès de Pro Santé Connect pour avoir la capacité de vérifier la validité d'un access token. Pour cela vous devez créer vos accès auprès de Pro Santé Connect en faisant une demande de création de nouveau service depuis le menu "Gérez votre service"
Les exigences de Pro Santé Connect
Contrairement à un FS le FD n'expose pas d'interface à l'utilisateur final.
Le FD n'étant pas exposé aux utilisateurs seule une partie des exigences du référentiel de Pro Santé Connect s'applique à son fonctionnement. En effet, il n'est pas nécessaire pour lui de répondre à certains critères comme la charte graphique, la nécessité de rafraîchir une session, la déconnexion, etc...
Un FS qui, par ailleurs, exposerait aussi son service sous forme de FD devra appliquer l'ensemble des exigences de Pro Santé Connect.
L'ensemble des exigences s'appliquant aux FD et aux FS se trouvent sur la page suivante : Exigences liées aux FD
Détail des flux
Interrogation du FD
Contexte : Le FS envoie un access token au fournisseur de données. Les détails de la communication entre le FS et le FD sont à définir entre les 2 protagonistes, PSC n'intervenant pas à ce niveau.
- Origine : FS
- Cible : Fournisseur de données
Méthode : POST
Requête :
| Paramètre | Obligatoire | Valeur |
|---|---|---|
| access token | Oui | 'access token' |
Validation de l'access token par le fournisseur de données
Contexte : Le fournisseur de données valide par introspection l'access token reçu de la part du FS
- Origine : FD
- Cible : Endpoint d'introspection de PSC
- Authentification : Le FD doit présenter son couple d'identifiants ou son certificat TLS
La demande
- Méthode d’appel : POST
- Body Content-type : application/x-www-form-urlencoded
| Paramètre | Obligatoire | Valeur |
| token | Oui | l'access_token émis par PRO Santé Connect et reçu par le FS qui a authentifié l'utilisateur |
| token_type_hint | Oui | 'access_token' |
Exemple pour un appel avec une authentification avec un client ID et un client secret :
POST /introspect HTTP/1.1
Host: PSC.introspection.endpoint
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic eyJhbGciOiJSUzI1NiIsInR5c
token=mF_9.B5f-4.1JqMLa réponse de Pro santé Connect
Le serveur renvoie les éléments suivants :
| Champ | Obligatoire | Valeur |
| Access_Token | Oui | le contenu de l'access token est renvoyé dans la réponse |
| Active | Oui | Booléen (True/false) qui indique si le jeton présenté est toujours actif ou non. |
| SubjectNameID | Oui | Identifiant National du Professionnel de Santé |
En cas d'access token invalide l'erreur suivante est renvoyée :
{
"active": false
}Appel du FD au UserInfo
Contexte : Le fournisseur de données utilise l'access token valide, en provenance du FS, pour récupérer le UserInfo. Cet appel est optionnel et dépend entièrement du FD et du service qu'il rend.
- Origine : FD
- Cible : Endpoint UserInfo de PSC
La demande
- Méthode d’appel : GET
| Paramètre Header HTTP | Obligatoire | Valeur |
| Authorization | Oui | l'access_token émis par Pro Santé Connect |
Exemple d'appel au UserInfo :
GET /userinfo HTTP/1.1
Host: PSC.UserInfo.endpoint
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c
La réponse de Pro Santé Connect au FD
Le serveur renvoie les éléments contenus dans le UserInfo et le contenu de la réponse dépend des scopes contenus dans l'access token reçus de la part du FS. Les scopes sont détaillés sur cette page.
En cas d'access token invalide l'erreur suivante est renvoyée :
{
"error": "invalid_token",
"error_description": "Token verification failed"
}La communication retour entre le FD et le FS doit être définie entre les 2 protagonistes.