Vulgarisation de OAuth 2.0

OAuth est un framework  ou protcole qui fourni un accès au serivce HTTP pour implémenter l’autorisation avec plusieurs extensions qui varie d'un "vendor" à l'autre, comme Google, Facebook, LinkedIn.

Un exemple d'extension est OpenID Connect OIDC qui permet de créer un profil pour l’authentification and SSO.

Third Party access.

Vocabulaire :

• scopes, flow ou grant type : définie comment le client va obtenir une autorisation (permission) à partir d'un Ressource Owner 
• Scope : permission, definie les actions que  l'application client peut faire sur une ressource donnée.
• token est lié à un Scope .
• Oauth 2.0 Actors :
• Ressource Owner : Celui qui possède la ressources (la données à protéger). Par exemple mon "profil LinkedIn" ou "Mur Facebook" est la données à protéger et je suis le propriétaire de cette ressources.
• Client est l’application (Mobile / Cloud ) qui veut accéder à la ressource que j'utilise et qui a besoin d’accéder à mon profil 
• Resource Server - Provider: L'endroit qui héberge les ressources protégé. C'est LinkedIn qui contient les données de mon compte.
• Authorization Server - OAuth Provider : c'est l’entité STS Security Token  service qui va donner le Jeton OAuth 2.0 d’accès  "Token" au Resource Server. Dans l'exemple suivant c'est Facebook ou Linkedin. Il est composé de 3 composnats :
• Authentification : une page de login qui s'affiche sur le Browser Identity provider  l'infrastructure IAM 
• Composant (consent server )qui demande le consentement de l'utilisateur authentifier pour la délegation de  droits d'accès au client (Application)
•  

Les Types de tokens :

• Access token : permet d'identifier le user, 2 types Sharing by Reference (sort de sessionid) coté serveur ou By value self-contained token (JWT) coté client. 
• Refresh token (stocker par le client ): permet de renouveler l'access tocken lorsqu'il expire, puet être utiliser pour demander un nouveau Access Token AT.
• Scopes se sont les permissions.
• Authorization Code (code):  Authorization Server  crée ce code et l'envoie au client (expire dans quelque minute).

 Credentilas (identifiants):

• Resource Owner Credentials 
• Client Credentials: ClinetId & ClientSecret
• Access token
• Refresh token
• Authorization Code

Client registration :

• Avec OAuth Provider 
• Le client fourni à OAuth Provider 
• Redirect URI
• Le Scope requis 
• En retour OAuth Provider  fourni au client 
• ClientId
• ClientSecret

OAuth 2.0 Grant types :
il y a différentes types de grants qui impact le flow :

• Client Credential grant : communication entre deux services. 
• Implicit grant type
• Resource owner password credentials grant type
• Authorization code grant type : est le plus utilisé . vous donnez votre accord d'accès à quelqu'un d'autre en votre nom.

https://docs.oracle.com/cd/E39820_01/doc.11121/gateway_docs/content/oauth_flows.html
Challenges :
Exemple de flux de délégation  d'accès avec OAuth 2.0:

1. Un utilisateur visite une application web tier et veut permettre  à cette application de publier les messages sur son mur Facebook. L'application Web à besoin de récupérer des tokens de Facebook, donc pour avoir ces token l'utilisateur va être rediriger vers Facebook.
2. Facebook affiche une pop up d'authentification(s'il n'est pas déjà authentifié), et demande le consentement de l'utilisateur pour donner les permissions à l'application web tier pour publier des messages dans son mur Facebook.
3. L'utilisateur s'authentifie et fournie son consentement à Facebook, et Facebook partage le token avec l'application Web tier pour une période limité et uniquement avec les autorisations accordées. L'application web tier, ne peut pas par exemple envoyé une demande pour ajouter des nouveaux amis, ou supprimer le message du status, télécharger une photos, etc ... avec ce token.
4. L'application web tier récupère le token de Facebook. Pour comprendre ce qui se passe dans cette étape nous devons comprendre comment les types de Grants fonctionne??? 
5. L'application web tier accède à l'API Facebook avec le token qui a été fourni par Facebook dans la étape précédente. L'API Facebook s'assure  que uniquement les requêtes qui ont un token valid peuvent avoir accès.