Je vais ajouter quelque chose ici que je ne pense pas être clairement indiqué dans les réponses ci-dessus:

• le flux de code D'autorisation permet au dernier access-token de ne jamais atteindre et de ne jamais être stocké sur la machine avec le navigateur / l'application . Le code d'autorisation temporaire est donné à la machine avec le navigateur / l'application,qui est ensuite envoyé à un serveur. Le serveur peut ensuite l'échanger avec un jeton d'accès complet et avoir accès aux API, etc. L'utilisateur avec le navigateur a accès à L'API uniquement via le 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/application est compromise leur auth-jeton qui pourrait être dangereux.

Tl; dr {[7] }n'utilisez pas de flux implicite si vous ne faites pas confiance à la machine des utilisateurs pour contenir des jetons, mais vous Faites confiance à vos propres serveurs.

La différence entre les deux est la suivante:

1. Dans le flux implicite, le jeton est renvoyé directement via l'URL de redirection avec le signe " # " et cela est principalement utilisé dans les clients javascript ou les applications mobiles qui n'ont 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 retourné avec "?"pour être lisible côté serveur, le côté serveur doit fournir le secret client cette fois-ci URL du jeton pour obtenir le jeton en tant qu'objet json à partir du serveur d'autorisation. Il est utilisé dans le cas où vous avez un serveur d'applications qui peut gérer cela et stocker le jeton 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, quel "code D'Autorisation" plus sécurisé tel qu'il est demande le secret sur le client et le jeton peut être envoyé entre le serveur d'autorisation et l'application cliente sur très sécurisé connexion, et le fournisseur d'autorisation peut restreindre certains clients à utiliser uniquement "code D'autorisation" et interdire implicite

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

Il est destiné à être utilisé pour les clients basés sur l'agent utilisateur (par exemple, les applications web à une seule page) qui ne peuvent pas garder un secret client car tout le code et le stockage de l'application sont facilement accessibles.

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

S'il vous plaît trouver les détails ici http://oauth2.thephpleague.com/authorization-server/which-grant/

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

Flux De Code D'Autorisation!!!

• Si vous avez un serveur d'applications web qui agit en tant que 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 api effectués par votre application
• Si vous ne voulez pas fuir votre jeton OAuth
• Si vous ne voulez pas que votre demande exécutez le flux d'autorisation chaque fois qu'il a besoin d'accéder aux données. Remarque: le flux D'octroi implicite n'accepte pas le jeton d'actualisation, donc 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 a besoin d'un accès.

Flux De Subvention Implicite!!!

• Lorsque vous n'avez pas de serveur D'applications Web pour agir en tant que Client OAuth
• Si vous n'avez pas besoin d'un accès de longue durée, c'est-à-dire que seul l'accès temporaire aux données est requis.
• Si vous faites confiance au navigateur où votre application s'exécute et que le problème est limité, le jeton d'accès fuit vers des utilisateurs non approuvés.

Flux implicite

Avantages

• Le plus simple à mettre en œuvre

Inconvénients

• jetons d'accès visibles pour 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 (par la Politique 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 nouveau fonctionnalités de sécurité et UX lorsqu'elles sont disponibles

Inconvénients

• doit implémenter plusieurs points de terminaison d'authentification

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

Du 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 implicite: refer: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 d'autorisations/autorisation que vous voyez dans google). Même est pas là dans implicite . Voir 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 utilisateur.

Lequel est le plus sûr et pourquoi?

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

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

C'est simple. Votre client n'est pas sécurisé. Voyons voir dans les détails.

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

Sur votre site Web, vous avez mis en place un lien qui dit. "Venez utiliser mon Application". En cliquant sur ce votre application web doit faire deux appels à Instagram API.

First envoyez une requête à 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 pasclient_secret, vous ne pouviez pas faire confiance au client (l'utilisateur et ou son navigateur qui essaient d'utiliser votre application). Le le client peut voir l'url ou le script java et trouver votre client_secrect facilement. C'est pourquoi vous avez besoin d'une autre étape.

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

, Puis vous faites un second appel de 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 fait à partir de notre serveur, nous pouvons utiliser en toute sécurité client_secret (qui montre comment nous sommes) avec {[13] } qui montre que l'Utilisateur a accordé client_id pour utiliser la ressource.

En Réponse, Nous aurons access_token