web-dev-qa-db-fra.com

Quelle est la différence entre les 2 flux de travail? Quand utiliser le flux de codes d'autorisation?

OAuth 2.0 a plusieurs flux de travail. J'ai quelques questions concernant les deux.

  1. Flux de codes d'autorisation - L'utilisateur se connecte à partir de l'application client. Le serveur d'autorisation renvoie un code d'autorisation à l'application. L'application échange ensuite le code d'autorisation pour le jeton d'accès.
  2. Flux d'octroi implicite - L'utilisateur se connecte à partir de l'application cliente, le serveur d'autorisation émet un jeton d'accès à l'application cliente directement.

Quelle est la différence entre les deux approches en termes de sécurité? Lequel est le plus sécurisé et pourquoi? 

Je ne vois pas pourquoi une étape supplémentaire (code d'autorisation d'échange de jeton) est ajoutée dans un flux de travail lorsque le serveur peut directement émettre un jeton d'accès.

Différents sites Web indiquent que le flux de code d'autorisation est utilisé lorsque l'application client peut conserver les informations d'identification en toute sécurité. Pourquoi?

oauthoauth-2.0
140
divyanshm

Le access_token est ce dont vous avez besoin pour appeler une ressource protégée (une API). Dans le flux de codes d'autorisation, il existe 2 étapes pour l'obtenir:

  1. L'utilisateur doit s'authentifier et renvoie une variable code au consommateur d'API (appelé "client").
  2. Le "client" de l'API (généralement votre serveur Web) échange la code obtenue dans # 1 contre un access_token, en s'authentifiant avec un client_id et un client_secret.
  3. Il peut ensuite appeler l'API avec le access_token.

Il y a donc un double contrôle: l'utilisateur qui possède les ressources mises en surface via une API et le client utilisant l'API (par exemple, une application Web). Les deux sont validés pour que l'accès soit accordé. Notez la nature "autorisation" de OAuth ici: l'utilisateur accorde l'accès à sa ressource (via la code renvoyée après l'authentification) à une application, l'application obtient un access_token et appelle de son côté.

Dans le flux implicite, l'étape 2 est omise. Ainsi, après l'authentification de l'utilisateur, un access_token est renvoyé directement, que vous pouvez utiliser pour accéder à la ressource. L'API ne sait pas qui appelle cette API. N'importe qui avec le access_token peut le faire, alors que dans l'exemple précédent, seule l'application Web le serait (ses composants internes ne sont normalement accessibles à personne).

Le flux implicite est généralement utilisé dans des scénarios où il n'est pas recommandé de stocker client id et client secret (un périphérique par exemple, bien que beaucoup le fassent quand même). C'est ce que le disclaimer signifie. Les utilisateurs ont accès au code client et peuvent donc obtenir les informations d'identification et prétendre devenir des clients ressources. Dans le flux implicite, toutes les données sont volatiles et rien n'est stocké dans l'application.

180
Eugenio Pace

Je vais ajouter quelque chose ici qui, à mon avis, n'est pas précisé dans les réponses ci-dessus:

  • Le flux de codes d'autorisation permet au jeton final access-token de ne jamais atteindre et d'être jamais stocké sur la machine avec le navigateur/l'application . Le code d'autorisation temporaire est attribué à la machine avec le navigateur/l'application, qui est ensuite envoyé à un serveur. Le serveur peut alors l'échanger avec un jeton d'accès complet et avoir accès aux API, etc. L'utilisateur avec le navigateur n'a accès à l'API que par le biais du serveur avec le jeton.
  • Le flux implicite ne peut impliquer que deux parties et le jeton d'accès final est stocké sur le client avec le navigateur/l'application. Si ce navigateur/cette application est compromis, son jeton d'authentification l'est aussi, ce qui pourrait être dangereux.

tl; dr n'utilisez pas de flux implicite si vous ne faites pas confiance à la machine des utilisateurs pour détenir des jetons mais que vous faites confiance à vos propres serveurs.

49
George Powell

La différence entre les deux est que:

  1. Dans le flux implicite, le jeton est renvoyé directement via une URL de redirection avec le signe "#", utilisé principalement dans les clients javascript ou les applications mobiles n'ayant pas de côté serveur, et le client n'a pas besoin de fournir son secret dans certaines implémentations. .

  2. Dans le flux de code d'autorisation, le code est renvoyé avec "?" pour être lisible par le côté serveur, alors le côté serveur doit fournir le secret client cette fois à l'adresse de jeton pour obtenir le jeton en tant qu'objet json à partir du serveur d'autorisation. Il est utilisé dans le cas où un serveur d'applications peut gérer cela et stocker le jeton d'utilisateur avec son profil sur son propre système, et principalement utilisé pour les applications mobiles courantes.

cela dépend donc de la nature de votre application cliente, lequel "code d'autorisation" plus sécurisé car il demande le secret sur le client et le jeton peut être envoyé entre le serveur d'autorisation et l'application cliente sur une connexion très sécurisée, et le fournisseur d'autorisation peut interdire à certains clients de n'utiliser que le "code d'autorisation" et d'interdire implicite 

13
Bassem Reda Zohdy

L'attribution implicite est similaire à l'attribution du code d'autorisation avec deux différences distinctes.

Il est destiné à être utilisé par les clients utilisant des agents d’utilisateur (par exemple, des applications Web à page unique) qui ne peuvent pas garder un client secret car tout le code de l’application et le stockage sont facilement accessibles.

Deuxièmement, au lieu que le serveur d'autorisation retourne un code d'autorisation qui est échangé contre un jeton d'accès, le serveur d'autorisation retourne un jeton d'accès.

Veuillez trouver les détails ici http://oauth2.thephpleague.com/authorization-server/which-grant/

3
Lutfor

Permettez-moi de résumer les points que j'ai appris des réponses ci-dessus et d'ajouter certaines de mes propres compréhensions.

Flux de code d'autorisation !!!

  • Si vous avez un serveur d'applications Web faisant office de client OAuth
  • Si vous voulez avoir un accès de longue durée
  • Si vous souhaitez avoir un accès hors ligne aux données
  • lorsque vous êtes responsable des appels d'api effectués par votre application
  • Si vous ne voulez pas laisser fuir votre jeton OAuth
  • Si vous ne souhaitez pas que votre application exécute un flux d'autorisation à chaque fois qu'elle a besoin d'accéder à des données. REMARQUE: le flux d'octroi implicite ne prend pas en compte le jeton d'actualisation. Par conséquent, si le serveur d'autorisation expire régulièrement les jetons d'accès, votre application devra exécuter le flux d'autorisation chaque fois qu'elle doit y accéder. 

Flux de subvention implicite !!!

  • Lorsque vous n'avez pas Web Application Server pour agir en tant que client OAuth
  • Si vous n’avez pas besoin d’un accès de longue durée, c’est-à-dire qu’un accès temporaire aux données est requis.
  • Si vous avez confiance dans le navigateur sur lequel votre application est exécutée et que le jeton d'accès risque de fuir vers des utilisateurs non fiables, la crainte est limitée.
1
Aman Tuladhar

Flux implicite

Avantages

  • Le plus simple à mettre en œuvre

Désavantages

  • Jetons d'accès visibles sur le navigateur
  • L'origine des jetons d'accès ne peut pas être déterminée
  • Les jetons d'accès ne peuvent pas expirer (selon les règles de Google)

Flux de code d'autorisation

Avantages

  • Le plus sécurisé
  • Les jetons d'accès et les jetons d'actualisation ne peuvent être créés que si un secret partagé est connu
  • Peut être amélioré avec de nouvelles fonctionnalités de sécurité et UX lorsqu'elles deviennent disponibles

Désavantages

  • Doit implémenter plusieurs points finaux d'authentification

Citation: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

1
vlazzle

Lequel est le plus sécurisé et pourquoi?

Les deux sont sécurisés, cela dépend de l'environnement dans lequel vous l'utilisez.

Je ne vois pas pourquoi une étape supplémentaire (code d'autorisation d'échange Pour le jeton) est ajoutée dans un flux de travail lorsque le serveur peut directement émettre un jeton d'accès.

C'est simple. Votre client n'est pas sécurisé. Voyons cela en détail. 

Considérez que vous développez une application avec Instagram API, vous enregistrez donc votre application avec Instagram et définissez le API's dont vous avez besoin. Instagram vous fournira client_id et client_secrect

Sur votre site Web, vous créez un lien qui dit. "Viens et utilise mon application". En cliquant sur ceci, votre application Web doit effectuer deux appels vers Instagram API.

First envoyer une demande à Instagram Authentication Server avec les paramètres ci-dessous.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.

Vous n'envoyez pas client_secret, vous ne pouviez pas faire confiance au client (l'utilisateur et/ou son navigateur essayant d'utiliser votre application). Le client peut voir l'URL ou le script Java et trouver facilement votre client_secrect. C'est pourquoi vous avez besoin d'une autre étape.

Vous recevez un code et un state. La code ici est temporary et n'est enregistrée nulle part.

Ensuite, vous appelez second pour Instagram API (à partir de votre serveur)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Comme l'appel est effectué depuis notre serveur, nous pouvons utiliser en toute sécurité client_secret (qui montre notre statut) avec code qui indique à l'utilisateur qu'il a accordé client_id pour utiliser la ressource.

En réponse, nous aurons access_token

0
Alireza Fattahi

D'un point de vue pratique (ce que j'ai compris), la principale raison d'avoir un flux de code Authz est:

  1. Prise en charge des jetons d'actualisation (accès à long terme par les applications pour le compte de l'utilisateur), non prise en charge implicitement: voir: https://tools.ietf.org/html/rfc6749#section-4.2
  2. Prise en charge de la page de consentement, qui est un endroit où le propriétaire de la ressource peut contrôler l'accès à fournir (type de page des autorisations/autorisations que vous voyez dans google). Same n'est pas là implicitement. Voir la section: https://tools.ietf.org/html/rfc6749#section-4.1 , point B).

"Le serveur d'autorisation authentifie le propriétaire de la ressource (via l'agent utilisateur) et détermine si le propriétaire de la ressource accorde ou refuse la demande d'accès du client"

En dehors de cela, en utilisant des jetons d'actualisation, les applications peuvent obtenir un accès à long terme aux données de l'utilisateur.

0
dvsakgec