2.1. {{base_url}}/v2/user

Ce connecteur permet d’obtenir l’identifiant de l’utilisateur IDN (son pseudonyme) s’il est connecté à l’IDN, la valeur 0 sinon.

Aucune association de session avec l’application partenaire n’est mise en place avec ce connecteur.

Il doit être appelé depuis le navigateur de l’utilisateur (donc par redirection depuis le serveur de l’application partenaire).

Dans le cas contraire, ce connecteur retournera toujours la valeur 0.

Ressource Informations

Limitation d'usage

Non

Authentification Utilisateur

Non

Authentification Application

Simple

Format(s) Réponse

HTTPS

Méthodes HTTP(s)

GET

 

Il n'y a pas de token d'échange avant de vérifier si un utilisateur est déjà connecté.

Exemple de requête

		GET https://__SERVER-URL__/anywhere/oauth/v2/user?		

Exemple de réponse l'utilisateur est connecté

		{"user_id":"<\pseudonyme>"}		

Exemple de réponse si l'utilisateur n'est pas connecté

		{"user_id":"0"}		

2.2.{{base_url}}/v2/me

Ce connecteur est dédié à être appelé depuis le navigateur de l’utilisateur (URL publique pour déclencher le processus de demande d’identification/autorisation de l’utilisateur pour l’application partenaire).

Le but est donc d’initier le processus d’association de session avec l’application partenaire et d’obtenir des informations sur l’utilisateur.

 

Ressource Informations

Limitation d'usage

Non

Authentification Utilisateur

OAuth2.0

Authentification Application

OAuth2.0

Format(s) Réponse

HTTPS

Méthodes HTTP(s)

GET

 

La demande de jeton d'autorisation se fait via le méthode "autorisation via un code" (voir chapitre 1.4.1.)

Le paramètre scope=profil sera utilisé lors de la demande de token.

Après la demande de jeton, la requête aura les paramètres décrits dans le tableau ci-dessous.

 

Paramètres

Valeurs

Description

access_token

ac0c11e4b07a1aec4a386c0495a29b544b7df911

Le jeton d’accès qui doit être envoyé au service Anywhere concerné

Exemple de Requête

		GET https://__SERVER-URL__/anywhere/oauth/v2/account/connect?access_token=ac0c11e4b07a1aec4a386c0495a29b544b7df911		

Exemple de retour json

		{ 
"id":"mbl",
"namePerson/friendly":"mbl",
"namePerson":"M LE-JAMBON Paul",
"namePerson/prefix":"M",
"namePerson/last":"LE-JAMBON",
"namePerson/first":"Paul",
"birthdate":"01-04-1984",
"contact/postalAddress/home":";;4 rue Franconville;;Paris;75050",
"contact/city/home":"Paris",
"contact/country/home":"France",
"contact/email":"mbl@somewhere.net",
"contact/phone/cell":"0607080910"
}

Les attributs pouvant être retournés par la requête sont définis dans le tableau ci-dessous.

Champs

Valeurs

Description

namePerson/friendly

([0-9a-zA-Z].[',-.]) (7 caractères max)

Pseudonyme IDN de l'utilisateur (invariant)

namePerson

([a-zA-Z].[',-.]) (82 caractères max)

Composition de la civilité, du nom et du prénom de l'utilisateur

namePerson/prefix

"M" ou "Mme"

Civilité de l'utilisateur

namePerson/last

([a-zA-Z].[',-.]) (38 caractères max)

Nom de famille

namePerson/first

([a-zA-Z].[',-.]) (38 caractères max)

Prénom

birthdate

Date ISO-8601

Date de naissance

contact/postalAddress/home

([0-9a-zA-Z].[',-.]) (300 caractères max)

Les SNA2 à 6 non vides dans l’ordre :

  1. SNA2 : Appartement, chez, sonnerie.. (Ex: Appartement A12 - Chez M. Georges Martin - Sonnerie 15) 

  2. SNA3 : Bâtiment, immeuble (Ex: Bâtiment B24 - Immeuble LATOUR)

  3. SNA4 : N° et libellé de la voie  

  4. SNA5 : Lieu-dit

  5. SNA6-1 : Ville

  6. SNA6-2 : Code Postale 

contact/city/home

([a-zA-Z].[',-.]) (50 caractères max)

SNA6-1 : Ville

contact/country/home

France

Pays

contact/email

[a-z.0-9]@ [a-z]. [a-z] (150 caractères max)

Courriel

contact/phone/cell

[00 00 00 00 00] ou [+33 0 00 00 00 00]

Mobile

 

N.B 1 : Ce service ne fonctionnera que si l'utilisateur est déjà connecté 

N.B 2 : Si l’utilisateur n’a pas donné son autorisation à partager ses données avec le partenaire, seul son pseudo sera retourné.

2.3. {{base_url}}/v2/account/connect

Ce connecteur est dédié à être appelé depuis le navigateur de l’utilisateur (URL publique pour déclencher le processus de demande d’identification/autorisation de l’utilisateur pour l’application partenaire).

Le but est donc d’initier le processus d’association de session avec l’application partenaire et d’obtenir des informations sur l’utilisateur.

L’URL qui déclenche le processus n’est autre que l’URL Authorize d’OAuth2. Le processus s’effectue en plusieurs temps (Voir chapitre 1.4.1).

Pour connecter l’utilisateur, il est nécessaire de demander le scope ‘openid’ lors de la requête d’autorisation.

Une fois la demande de connexion/consentement utilisateur exécuté avec succès, le serveur d’autorisation retourne un code d’autorisation. Ce code est ensuite échange contre un jeton d’accès et un ID Token.

 

Après avoir décrypté l’ID Token (base64 decode), l’application partenaire doit valider ce jeton.

 

Validation du contenu de l’ID Token :

 

  1. L’application partenaire doit vérifier que la valeur du champ iss (issuer) correspond bien à l’URL du provider d’identité (en l’occurrence, l’URL d’accès d’AnyWhere)
  2. L’application partenaire doit vérifier que la valeur du champ aud (audience) correspond bien à clé unique du Client (afin de bien vérifier que l’application est bien le destinataire du jeton)
  3. L'heure courante ne doit pas dépasser l'heure représentée par le champ exp (expire) (on peut permettre une certaine petite marge de manœuvre pour tenir compte des décalages d'horloge).
  4. L’application partenaire peut vérifier le champ iat (issue at) afin de rejeter les jetons qui ont été émis un peu trop longtemps après la requête d’autorisation et ceux afin d’éviter d’éventuelles attaques (cette période de temps est définit par le Client).
  5. Si le paramètre nonce a été envoyé dans la requête d’autorisation, le champ nonce doit être contrôlé et correspondre au paramètre envoyé. Il est utilisé pour éviter les attaques de type REPLAY.
  6. L’application partenaire peut si elle le souhaite vérifier la signature du jeton (cf 2.2.1.)

 

 

Exemple de retour valide :

		{
    "access_token": "a26b488e647a6e9eecaca1f4232fad936a5dfc57",
    "expires_in": 3600,
    "token_type": "Bearer",
    "scope": "openid email address phone profile",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
                 eyJpc3MiOiJodHRwczpcL1wvYW55d2hlcmUtbG9jYWwuaWRuLmxhcG9zdGUuZnIiLCJzdWIiOiJtbGV3YWx0ZXJAZWRpeGlzLmNvbSIsImF1ZCI6Il9jMDM2YjBiNmY5N2EzOTQxOTBhMDBmMmQzNmIyMTMwOTE5MzhkMjI1IiwiaWF0IjoxNDA5OTA3ODQxLCJleHAiOjE0MDk5MTE0NDEsImF1dGhfdGltZSI6MTQwOTkwNzg0MSwibmFtZSI6Ik0uIExFV0FMVEVSIE1heGltZSIsImdlbmRlciI6Im1hbGUiLCJmYW1pbHlfbmFtZSI6IkxFV0FMVEVSIiwiZ2l2ZW5fbmFtZSI6Ik1heGltZSIsIm5pY2tuYW1lIjoiTWF4TGFNZW5hY2UiLCJiaXJ0aGRhdGUiOiIxOTkwLTEwLTA1IDIwOjMwOjAwIiwiZW1haWwiOiJtbGV3YWx0ZXJAZWRpeGlzLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJhZGRyZXNzIjp7ImZvcm1hdHRlZCI6bnVsbCwicGxhY2UiOm51bGwsImRldGFpbHMiOm51bGwsInN0cmVldF9hZGRyZXNzIjpudWxsLCJsb2NhbGl0eSI6bnVsbCwiY2l0eSI6bnVsbCwicG9zdGFsX2NvZGUiOm51bGwsImNvdW50cnkiOm51bGwsImFkZHJlc3NfdmVyaWZpZWQiOm51bGx9LCJwaG9uZV9udW1iZXIiOiIrMzM2ODg4ODg4ODgiLCJwaG9uZV9udW1iZXJfdmVyaWZpZWQiOmZhbHNlfQ.
                 rndyz2iS0Tb6o7uAIi-SaRhMftHxQ-zrzapyoUNxGdg"
}

2.4. {{base_url}}/v2/account/logout

L’appel à ce connecteur met fin à la session IDN de l’utilisateur précédemment authentifié, retournant un cookie null. Elle déconnecte l’utilisateur du serveur IDN, mais ne gère pas la déconnection de la session locale des applications partenaires.

 

Ressource Informations

Limitation d'usage

Non

Authentification Utilisateur

Non

Authentification Application

OAuth2.0

Format(s) Réponse

HTTPS

Méthodes HTTP(s)

GET

 

La demande de jeton d'autorisation se fait via le méthode "autorisation serveur à serveur" (voir chapitre 1.4.2)

Après la demande de jeton, la requête aura les paramètres décrits dans le tableau ci-dessous.

 

Paramètres

Valeurs

Description

id_token_hint

ac0c11e4b07a1aec4a386c0495a29b544b7df911

La clé unique du Client, obtenu lors du processus d’inscription de l’application partenaire.

post_logout_redirect_uri1

https://www.aplication.url

URL de l’application partenaire sur laquelle l'utilisateur doit être redirigé après avoir été déconnecté avec succès.

state xxx Le client envoie ce paramètre lors de la demande de code d’autorisation, il sera retourné tel quel par le serveur d’autorisation dans la réponse et pourra donc être comparé par le client avant la demande d’échange du code par un jeton d’accès. Ce paramètre correspond généralement à un hash unique d’un nombre aléatoire qui sera stocké dans la session de l’utilisateur. Il est utilisé afin d’empêcher l’exploitation de failles CSRF (cf. RFC 6749 — Cross-Site Request Forgery)

 

1paramètre optionnel sauf si plus d’une URL a été enregistré pour un client donné.

Exemple de requête

		{{base_url}}/v2/logout?
state=xxx&
id_token_hint=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.
              eyJpc3MiOiJodHRwczpcL1wvYW55d2hlcmUtbG9jYWwuaWRuLmxhcG9zdGUuZnIiLCJzdWIiOiJtbGV3YWx0ZXJAZWRpeGlzLmNvbSIsImF1ZCI6Il9jMDM2YjBiNmY5N2EzOTQxOTBhMDBmMmQzNmIyMTMwOTE5MzhkMjI1IiwiaWF0IjoxNDEwMzU4OTA5LCJleHAiOjE0MTAzNjI1MDksImF1dGhfdGltZSI6MTQxMDM1ODkwOSwibmFtZSI6Ik0uIExFV0FMVEVSIE1heGltZSIsImdlbmRlciI6Im1hbGUiLCJmYW1pbHlfbmFtZSI6IkxFV0FMVEVSIiwiZ2l2ZW5fbmFtZSI6Ik1heGltZSIsIm5pY2tuYW1lIjoiTWF4TGFNZW5hY2UiLCJiaXJ0aGRhdGUiOiIxOTkwLTEwLTA1IiwiZW1haWwiOiJtbGV3YWx0ZXJAZWRpeGlzLmNvbSIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlfQ.
              6-Vwm6_Ipz6dkjviOfMttHpGQiOn7526MPJMYbQXNxg

Réponse

La réponse du service OAuth d’IDN se fait par redirection. Le processus de réponse suit les étapes suivantes :

  • Contrôle du paramètre post_logout_redirect_uri s’il est présent.
  • Validation du jeton id_token (contrôle signature, vérification session active utilisateur, etc…)

Si la déconnexion s’est effectuée avec succès, le serveur IDN redirige l’utilisateur vers l’URL de redirection de l’application partenaire avec en paramètre user_id=0.

2.5. {{base_url}}/v2/status/badge/create

Ce connecteur permet d’obtenir les informations nécessaires à l’affichage du badge d’un ou plusieurs utilisateurs IDN. L’authentification de l’application partenaire est simple afin de permettre l’exécution de la requête depuis le navigateur client (AJAX par exemple). L’application partenaire peut néanmoins utiliser ce connecteur pour vérifier la validité d’un utilisateur.

Ressource Informations

Limitation d'usage

Non

Authentification Utilisateur

Non

Authentification Application

OAuth2.0

Format(s) Réponse

HTTPS

Méthodes HTTP(s)

POST

 

La demande de jeton d'autorisation se fait via le méthode "autorisation serveur à serveur" (voir chapitre 1.4.1)

Après la demande de jeton, la requête aura les paramètres décrits dans le tableau ci-dessous.

Paramètres

Valeurs

Description

access_token

ac0c11e4b07a1aec4a386c0495a29b544b7df911

Le jeton d’accès qui doit être envoyé au service Anywhere concerné



Exemple d'envoi :

		
POST /v2/status/badge/create HTTP/1.1
Host: anywhere-sandbox.idn.laposte.fr
Content-Type: application/json
Accept: application/json
Authorization: Bearer 1fb2af5201eb4b87ef26cc9bae56e6c6255c18ac
Cache-Control: no-cache
Postman-Token: debb1324-4ebf-1556-c49e-b5c25b73ef6b
 
{
    "list":["dbo-46mn", "aay-ry74"]
}

Exemple de retour :

		
{"token":"f33bf400be344ac0633f943438b828c0"}
Ce token sera à utiliser dans le jsdk présenté sur https://anywhere.idn.laposte.fr/jsdk/anywhere-2.0.js
		
<script>
idn.anywhere.setup({
    client_id:“_ce85bad96eed75f0f7faa8f04a48feedd56b4dcb”,
    badge_token:”f33bf400be344ac0633f943438b828c0”
});
</script>