Documentation sur l'authentification

Authentification


Utiliser le protocole OAuth 2.0 pour accéder aux Apis Concierge

Les API Concierge utilisent le protocole OAuth 2.0 pour l'authentification et l'autorisation. Concierge prend en charge les scénarios OAuth 2.0 commun tels que ceux pour les serveurs Web, les applications installées côté client.

Pour commencer, obtenez les informations d'identification des clients OAuth 2.0 dans Mes applications. Ensuite, votre application client demande un jeton d'accès à partir du serveur d'autorisation Concierge, récuperez ce jeton à partir de la réponse et envoyez le dans votre header lors de vos appels à l'api Concierge.


Compte développeur


Pour pouvoir utiliser l'api Concierge, il est nécessaire de se connecter avec votre compte Concierge. Si vous ne possédez pas de compte chez Concierge, vous pouvez vous inscrire en cliquant ici.

Un concierge n'est pas nécessaire pour l'utilisation de l'api. Le compte développeur est utilisable sur la plateforme développeur et aussi en tant que compte utilisateur classique de Concierge.


Enregistrez votre application


Pour obtenir les identifiants nécessaires à l'obtention de votre access_token, vous devez ajouter une nouvelle application.

Quelques informations sont nécessaires pour sa création. Certaines seront affichées à l'utilisateur lors du processus d'autorisation.

Décrivez au maximum ce que votre application peut apporter aux utilisateurs de Concierge.


Obtenez votre authorization code


Ce jeton sera ensuite utilisé pour demander à un utilisateur de permettre à votre système d'accéder à ses données à l'aide de l'API Concierge. Vous devez effectuer cette étape une seule fois par utilisateur.

Notez que la paire token / secret demandée n'est pas utilisée dans les demandes d'accès aux données. Elle est uniquement utilisée pour créer la demande d'autorisation et pour générer l'access_token

Tout d'abord, l'utilisateur reçoit un lien d'authorization code qui ressemble à ce qui suit :

https://auth.concierge.eu/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE&scope=SCOPES&response_type=code

Paramètres

Nom Description
client_id Client ID de votre application
redirect_uri L'url sur laquelle nous ferons la redirection après l'autorisation de l'utilisateur. L'URI doit correspondre au redirect_uri utilisé lors de l'enregistrement de votre application.
Scope La liste délimitée par un espace des étendues de subventions que vous souhaitez avoir la permission d'accéder au nom de l'utilisateur. Liste des scopes disponibles (read_concierge write_concierge read_user)

Exemple de requête

https://auth.concierge.eu/oauth/authorize?client_id=d8cdba9e-8af6-427d-9771-7446850c5800&redirect_uri=http://google.fr&state=arm8Au68Gbj_qBK_ljPgSg&scope=read_concierge%20write_concierge%20read_user&response_type=code


Réception de la redirection

Une fois que l'utilisateur Concierge authentifie et autorise votre application, Concierge émettra une redirection HTTP 302 vers l'url de redirection passée en paramètre.

Sur cette redirection, vous recevrez votre code d'autorisation, à usage unique, qui expire dans les dix (10) minutes suivant son émission.

GET https://your-redirect-uri/?code=AUTHORIZATION_CODE&state=YOUR_STATE

Obtenez votre access_token


Échangez votre authorization code pour un access_token, ce qui vous permettra de faire des demandes au nom d'un utilisateur.

POST /oauth/token HTTP/1.1
Host: auth.concierge.eu
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&grant_type=authorization_code&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Paramètres

Nom Description
client_id Client ID de votre application
client_secret Client Secret de votre application
redirect_uri L'url de redirection que vous avez utilisée à l'étape précédente.
grant_type Dans cette étape, cela doit être défini sur autorisation_code
code L'authorization code reçu à l'étape précédente

Par défaut, ces paramètres doivent être x-www-form-urlencoded et spécifiés dans le corps de la demande

Réponse

{
    "access_token": "xxx",
    "token_type": "Bearer",
    "expires_in": 1199,
    "refresh_token": "xxx"
}

L'access_token est valable pour une période de temps limitée en secondes, décrite par expires_in . Le refresh_token n'expire pas et peut être utilisé pour obtenir un nouveau access_token à tout moment. En effet, l'application appelante est toujours autorisée à accéder à l'API pour le compte de cet utilisateur.


Utiliser l'access_token


Passez l'access_token renvoyé à l'étape précédente en tant que Bearer token dans l'en-tête Autorisation.

OAuth2 Token (envoyé dans le header)

GET /api/concierges HTTP/1.1
Host: api.concierge.eu
Authorization: Bearer ACCESS_TOKEN
Cache-Control: no-cache

Rafraichir l'access_token


Lorsque l'access_token de l'utilisateur a expiré, vous pouvez obtenir un nouvel access_token en échangeant le refresh_token associé à l'access_token.

POST /oauth/token HTTP/1.1
Host: auth.concierge.eu
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
refresh_token=REFRESH_TOKEN&grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Une fois que vous avez utilisé refresh_token pour obtenir un nouvel access_token, vous obtiendrez également un nouveau refresh_token en lieu et place du précédent.


Erreurs connues


La longueur de l'access_token et refresh_token est susceptible de varier avec le temps. Utilisez un type de données de longueur variable sans taille maximale spécifique pour stocker les jetons d'accès.

Nom Description
invalid_request Les paramètres requis n'étaient pas fournis.
invalid_client Le client ID ou secret fourni n'est pas valide, ces paramètres doivent être x-www-form-urlencoded et spécifiés dans le corps de demande.
invalid_grant Les grant_type valides sont authorization_code et refresh_token.

Pour toutes autres erreurs, se référer au code HTTP de retour