oauth - L'Authorization Server de la Sécurité Sociale

Aperçu

Système basé sur OAuth 2.0 qui est un protocole de sécurité permettant à une personne de déléguer ses droits d’accès à une ressource

Ce protocole permet à une application d’agir au nom de quelqu’un sans devoir fournir les informations secrètes de cette personne. Ce protocole est utilisé par exemple pour sécuriser les services REST. L’application cliente récupère auprès d’un serveur d’authentification un Access Token qui va lui permettre d’accéder à une ressource protégée au nom du propriétaire de la ressource.

L’Authorization Server de la Sécurité Sociale est destiné à deux usages distincts et complémentaires :

1. Il implémente les spécifications liées à OAuth2 afin de permettre aux applications (dans et en-dehors du cercle de confiance) d’accéder aux API REST de la Sécurité Sociale dans le respect des règles d’accès et, le cas échéant, avec l’accord temporaire de l’utilisateur authentifié et autorisé.

OAuth2 définit plusieurs flux d’autorisations à utiliser dans différentes situations. Chaque flux a un niveau de sécurité différent et doit être utilisé dans des situations particulières. Le flux le plus général et le plus sécurisé est celui de l’Authorization Code et les autres sont des optimisations de celui-ci.

• Authorization Code

Ce flux permet dans un premier temps d’obtenir un Access Token ainsi qu’un Refresh Token. Par la suite, ce flux permet aussi le renouvellement d’un Access Token au moyen du Refresh Token reçu. Un Refresh Token a une durée de vie plus longue et peut être fourni à l’Authorization server pour renouveler l’Access Token. Le Refresh Token n’étant valable qu’une seule fois, un nouveau Refresh Token est fourni lors de ce renouvellement. Cette méthode permet un renouvellement de l’Access Token sans nécessiter la présence du Resource Owner.

• Client Credential

Ce flux permet d’utiliser OAuth2 dans le cas où une application n’agit pas au nom d’une tierce partie mais en son nom propre. Dans ce scénario, le client est donc le Resource Owner et il n’y pas besoin d’échanger un Authorization Code ni de donner son accord. Il n’est pas nécessaire de fournir un Refresh Token lors de ce flux car le client étant toujours présent pour s’authentifier, le Refresh Token perd son utilité.

• Implicit

Le point fort du flux Authorization Code Grant est qu’il garde séparées les informations propres aux différents composants. Cependant, lorsque le Client est une application s’exécutant entièrement au sein d’une même page web (en Javascript), cette séparation est impossible. L’échange d’informations menant à l’obtention d’un Authorization Code est donc inutile. Dans le flux d’autorisation implicite, on considère que le Resource Owner est toujours présent car le client est exécuté au sein d’un web browser. Donc il est toujours possible de recommencer le processus complet si nécessaire. Cependant, recommencer le processus complet implique de demander l’autorisation au Resource Owner à chaque fois qu’on veut obtenir un nouvel Access Token ce qui peut très vite devenir dérangeant pour le Resource Owner.

2. Il agit comme OpenID Provider tel que défini par la spécification OpenID Connect afin de permettre aux applications (dans et en-dehors du cercle de confiance) d’obtenir les attributs d’identité et de contexte d’un utilisateur authentifié, le cas échéant avec son accord temporaire.

OpenID Connect est une couche d'identification basée sur le protocole OAuth 2.0, qui autorise les clients à vérifier l'identité d'un utilisateur final en se basant sur l'authentification fournie par un serveur d'autorisation, en suivant le processus d'obtention d'une simple information du profil de l'utilisateur final.

OpenID Connect définit deux nouveaux concepts permettant l’authentification :

• ID Token

Dans un premier temps, OpenID Connect rajoute un ID Token qui accompagne l’Access Token. Cet ID Token permet de décrire le processus d’authentification et contient l’identifiant de l’utilisateur, l’heure de l’authentification ainsi que différentes informations à propos de l’authentification elle-même.

• UserInfo Endpoint

Dans un second temps, OpenID Connect ajoute un Endpoint à l’Authorization Server permettant de récupérer des informations à propos de l’utilisateur telles que son nom ou son adresse email.

 

Au niveau de l’architecture OAuth, différents API REST sont ainsi mises en place :

• Authorization Endpoint

L’Authorization Endpoint est celui par lequel une application cliente peut obtenir d’un utilisateur authentifié et autorisé qu’il lui délègue temporairement son droit d’accéder à une API REST. L’Authorization Endpoint s’appuie sur la webapp de login (WALI) pour l’authentification de l’utilisateur, et sur le PDP de UAM pour évaluer les règles d’accès s’appliquant à l’autorisation demandée.

Dans le cas d’OpenID Connect, l’Authorization Endpoint est aussi celui par lequel l’application cliente pourra obtenir, sous la forme d’un « ID Token », les attributs d’identité et de contexte de l’utilisateur authentifié qui aura donné son accord temporaire dans ce but.

• Token Endpoint

Le Token Endpoint est celui par lequel une application cliente authentifiée et autorisée peut obtenir un « Access Token » (et éventuellement un « Refresh Token ») matérialisant son droit d’accéder à une API REST. Dans le cas d’une application demandant une autorisation à laquelle elle a droit (sans délégation de la part d’un utilisateur), le Token Endpoint s’appuie sur le PDP de UAM pour évaluer les règles d’accès s’appliquant à l’autorisation demandée.

• Introspection Endpoint

L’Introspection Endpoint est celui par lequel les API REST et l’infrastructure SOA peuvent vérifier la validité d’un Access Token et obtenir d’une part les attributs d’identité et de contexte de l’utilisateur et/ou de l’application cliente, et d’autre part les autorisations matérialisées par l’Access Token.

• User info Endpoint

Dans le contexte d’OpenID Connect, le User Info Endpoint est celui par lequel les applications clientes ayant obtenu l’accord d’un utilisateur authentifié pourront obtenir ses attributs d’identité et de contexte.

Public cible

Toutes les applications et services sécurisés du portail de la sécurité sociale, et essentiellement ceux qui font intervenir des technologies REST.

Les applications et services peuvent concerner:

• Citoyen
• Personne travaillant pour une entreprise
• Personne morale (entreprise, institution, ...)
• Professionnel

Conditions d'intégration

Prendre contact avec l'équipe support-iam qui vous expliquera les différentes étapes à suivre pour sécuriser votre application et/ou service.

Documentation

• Documentation générale
• Procédure et Processus IAM

Contact

Contact : ReuseOperational@smals.be