Page Comparison

...

La documentation est accessible aux adresses suivantes :

• backend core : https://core.fairandsmart.com/doc/api.htmlswagger-ui/

• backend data : https://data-fr01.fairandsmart.com/doc/api.htmlswagger-ui/

• backend timestamp : https://tsa.fairandsmart.com/apiswagger-docui/

Mise en place d’un compte technique pour l’utilisation de l’API

...

La première étape est de définir un rôle spécifique et lui attribuer uniquement les opérations dont il aura besoin, par exemple Générer un lien de collecte de consentement et Évaluer le statut d'un consentement avec une requête.

La seconde étape est d’inviter cet utilisateur technique : pour cela suivre la procédure d’invitation d’un collaborateur en précisant qu’il doit bénéficier uniquement du rôle nouvellement créé.

Puis procéder à l’onboarding du compte technique de manière standard.

Authentification des accès

L’accès à l’API se fait via un jeton obtenu via OAuth2 d’acces (access_token) via auprès du serveur d’authentification OAuth2 https://auth.fairandsmart.com/ . Les access token ayant une durée de vie nettement plus courte que celle des refresh token (5 minutes vs. 30 jours), il est conseillé de conserver une copie de ce dernier Ce jeton est obtenu après deux appels :

• un premier pour obtenir un refresh_token à longue durée de vie (30 jours) mais qui ne sert qu'à récupérer des access_token ;

• un second pour obtenir un access_token à courte durée de vie (5 minutes) qui lui ne sert qu'à requêter notre API ;

Exemple de cinématique (il vous faudra un environnement linux équipé de curl et jq pour le faire fonctionner) :

# récupération d'un refresh_token
export REFRESH_TOKEN=$(/usr/bin/curl --fail --silent \
  https://auth.fairandsmart.com/auth/realms/FairAndSmart/protocol/openid-connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode username=MY_USERNAME \
  --data-urlencode password=MY_PASSWORD \
  --data-urlencode grant_type=password \
  --data-urlencode client_id=fsorg \
  | jq -r '.refresh_token')

# récupération d'un access_token
export ACCESS_TOKEN=$(/usr/bin/curl --fail --silent \
  https://auth.fairandsmart.com/auth/realms/FairAndSmart/protocol/openid-connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
    --data-urlencode 'grant_type=refresh_token' \
    --data-urlencode "refresh_token=${REFRESH_TOKEN}" \
    --data-urlencode "client_id=fsorg" \
  | jq -r '.access_token')

A la fin des appels, l’environnement contient deux variables : REFRESH_TOKEN (validité 30 jours) pour récupérer d’autres access_token, et ACCESS_TOKEN (validité 5 minutes) pour interroger l’API.

Bien qu’il soit possible d’obtenir un access_token dès le premier appel, il est conseillé de prendre l’habitude de passer par le mécanisme refresh_token → access_token pour éviter d’avoir à ouvrir une nouvelle session à chaque appel REST, et le renouveler uniquement si nécessaire.

...

Un User ID doit être passé aux appels de génération des endpoints de collecte de consentement (https://core.fairandsmart.com/doc/api.html#operation/getConsentEndointJsonswagger-ui/). Dans la mesure où cet identifiant figure en clair dans le registre de consentements, sa définition doit présenter des garanties appropriées.

...