web-dev-qa-db-fra.com

Flux IdentityServer

IdentityServer prend en charge différents flux OpenId Connect définis dans l'énumération Flows et définis pour les clients. Il y a aussi des exemples pour chaque type de flux et de nombreuses références à eux dans la documentation, mais je n'ai pas pu trouver une liste de définition simple de ce que les flux sont dans documentation comme s'ils étaient trop évidents pour être expliqués par des mots. Mais je suppose que non. Pouvez-vous s'il vous plaît en dire plus sur les différences de ceux-ci, peut-être pouvons-nous ajouter cela aux documents?

Alors, quels sont: flux implicite , mot de passe du propriétaire de la ressource flux, code d'autorisation flux, informations d'identification client flux, flux personnalisé et flux hybride ? Quels sont également les flux OAuth et ceux qui sont des flux OpenID Connect?

Merci!

oauth-2.0openidthinktecture-ident-serveropenid-connectidentityserver3
53
orad

J'ai fait face au même problème, actuellement le travail est toujours en cours. quand j'aurai fini la documentation, je pourrais la poster ici. pour le moment: veuillez vérifier le projet:

Enrichir la documentation IdentityServer avec OIDC et OAuth2 Flows section # 7

Mise à jour: flux OIDC et OAuth2

38
Jawad Al Shaikh

Du premier lien de lessPrivilage: et Aharon Paretzki OAuth 2 simplifié

Les flux décident de la façon dont le jeton ID (c'est-à-dire le code d'autorisation) et le Jeton d'accès (c'est-à-dire 'le jeton') sont retournés au client:

Flux de code d'autorisation : OAuth 2.0 flux dans lequel

  • un code d'autorisation est renvoyé par le point de terminaison d'autorisation
  • et tous les jetons (en deuxième étape, en échange du code d'autorisation) sont renvoyés du point de terminaison du jeton
  • Utilisé pour les appels basés sur serveur (API) qui peuvent maintenir la confidentialité de leur secret client. Permet une sécurité renforcée, tant que personne ne peut accéder au "secret client".

Flux implicite : OAuth 2.0 flux dans lequel

  • tous les jetons sont retournés directement depuis le point de terminaison d'autorisation
  • et ni le point de terminaison de jeton ni un code d'autorisation ne sont utilisés.
  • Utilisé pour les applications mobiles et basées sur le Web, qui ne peuvent pas maintenir la confidentialité du secret client, il est donc nécessaire que le jeton soit émis par le serveur d'authentification lui-même. Ceci est moins sécurisé et il est recommandé que le serveur soit configuré pour refuser flux implicite les appels à l'utilisation de l'API et ne l'autoriser que pour les applications basées sur navigateur et mobiles.

Flux hybride : OAuth 2.0 flux dans lequel

  • un code d'autorisation est renvoyé par le point de terminaison d'autorisation,
  • certains jetons sont retournés directement à partir du point de terminaison d'autorisation, et d'autres sont retournés (dans un deuxième temps, en échange du code d'autorisation) à partir du point de terminaison de jeton.
  • Utilisé là où les deux flux sont nécessaires.
20
pashute

voir les spécifications - tout a déjà été écrit:

http://openid.net/specs/openid-connect-core-1_0.html et http://tools.ietf.org/html/rfc6749

en plus j'ai récemment écrit un résumé qui le décompose pour différents types d'application:

http://leastprivilege.com/2016/01/17/which-openid-connectoauth-2-o-flow-is-the-right-one/

10
leastprivilege

Les flux définis dans OAuth2 ne sont que plusieurs façons pour un client de recevoir un access token à partir d'un serveur fournisseur d'identité; le IdentityServer dans ce cas. Comprendre les flux ne sera facile que si vous comprenez parfaitement les entités spécifiées dans les diagrammes de flux tels que Resource Owner, User Agent, et Resource Server. Il y a quelques brèves explications sur ces entités (rôles, précieusement) dans ici .

Flux de code d'autorisation : émet un authorization code avant d'émettre un access token.

  • Un client demande un authorization code.
  • IdentityServer Valide le client et demande au propriétaire de la ressource d'accorder l'autorisation d'émettre un authorization code.
  • Le client demande alors un access token avec le authorization code
  • Le serveur d'autorisation émet un access token directement au client.

Flux de code implicite : émet un access token même sans authorization code à condition de.

  • Un client demande un access token directement.
  • IdentityServer ignore la validation du client (dans certains scénarios, il le fait partiellement) mais demande toujours au propriétaire de la ressource d'accorder l'autorisation d'émettre un access token
  • Ce flux n'émet jamais de authorization code.

Le flux implicite est considéré comme le flux idéal pour un client utilisant des langages de script comme javascript car le client n'a pas à demander un authorization code Et un access token séparément, réduisant ainsi un aller-retour réseau pour le client.

Flux d'informations d'identification du client : émet un access token sans l'autorisation d'un propriétaire de ressource.

  • Un client demande directement un jeton d'accès.
  • IdentityServer valide le client et émet un access token tout de suite.

Ceci est idéal lorsque le client est également un propriétaire de ressource, il n'a donc pas besoin d'autorisations d'autorisation jusqu'à access token.

Flux du propriétaire de la ressource : émet un access token si un client possède les informations d'identification du propriétaire de la ressource (par exemple, Id/Password)

  • Un client demande un access token directement.
  • IdentityServer valide le client et vérifie l'identité du propriétaire de la ressource.
  • S'il est valide, le client obtient access token instantanément.

Ce flux est idéal pour les clients que vous pensez qu'il est absolument sûr de partager les identifiants et les mots de passe avec eux.

Flux hybride (flux OIDC) : émet un authorization code Et un access token.

Il s'agit d'une combinaison de Authorization code flow et Implicit code flow. C'est pourquoi cela s'appelle Hybrid.

Flux personnalisé

Il s'agit littéralement d'un flux personnalisable. Cela peut être utilisé lorsque vous avez besoin d'un processus d'authentification/validation spécifique dans votre entreprise à côté de toutes les spécifications de protocole dans OAuth2.

IdentityServer est bien conscient de ce genre de situation et prend en charge les extensibilités par conception. Le modèle d'usine, le modèle de décorateur et l'IoC/DI vous faciliteront la mise en œuvre de fonctionnalités supplémentaires sur votre IdentityServer.

6
hina10531