48

IdentityServer obsługuje różne emisje OpenId Connect zdefiniowane w wyliczeniu Flows i ustawione dla klientów. Są też próbki dla każdego typu przepływu i wiele odniesień do nich w dokumentach, ale nie mogłem znaleźć prostej listy definicji tego, jakie przepływy są w tym przypadku, ponieważ są zbyt oczywiste, aby wyjaśnić je słowami. Ale myślę, że nie są. Czy możesz powiedzieć coś więcej o różnicach tych, może możemy to dodać do dokumentów?IdentityServer Flows

Więc jakie są: ukryte przepływu, właściciel zasobu hasło poświadczeń przepływu, upoważnienie kod przepływu, poświadczenia klienta przepływowe, zwyczaj grant przepływu i hybrydowy przepływu? Również które z nich są przepływami OAuth, a które są przepływami OpenID Connect?

Dzięki!

Odpowiedz

8

zobaczyć specyfikację - to wszystko zostało już napisane:

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

oprócz I niedawno pisemne podsumowanie, które rozkłada go dla różnych typów aplikacji:

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

+1

Wiem, ale szukałem krótszego opisu. Znalazłem bardzo przydatny opis tego (http://leastprivilege.com/2014/10/10/openid-connect-hybrid-flow-and-identityserver-v3/) na twoim blogu. – orad

+1

Uważam również, że jest to największy problem z serwerem tożsamości, ponieważ istnieją ograniczone podstawowe informacje o produkcie. Około miesiąca na wdrożenie ram niezwykle użyteczne dokumenty okażą się przydatne, ale krzywa uczenia się nie jest zbyt stroma. – Dillorscroft

+1

Rzeczywiście dowiedziałem się więcej o serwerze tożsamości za pośrednictwem dokumentów implementacyjnych Auth0.com, a następnie wróciłem do serwera tożsamości. – Dillorscroft

18

Od leastPrivilage pierwszego linku: i Aharon Paretzki's OAuth 2 Simplified

Przepływy zdecydować, w jaki sposób ID tokena (tj. kod autoryzacyjny) i token dostępu (tj. „Znacznik”) są zwrócone do klienta:

kodu autoryzacji przepływu: Przepływ OAuth 2.0, w którym

  • kodu autoryzacyjnego jest zawracany z autoryzacji końcowy
  • i wszystkich znaczników (jako drugi etap, w zamian za kod autoryzacyjny) są zwracane z tokena Endpoint
  • Wykorzystywane do wywołań opartych na serwerze (API), które mogą zachować poufność swojego tajnego klienta. Pozwala na większe bezpieczeństwo, o ile nikt nie ma dostępu do "tajemnicy klienta".

Przepływ niejawny: OAuth 2.0 Przepływy w którym

  • wszystkie żetony zwrócone są bezpośrednio z zezwolenia Endpoint
  • i ani Reklamowe Endpoint ani kod autoryzacji są używane.
  • Używany do aplikacji mobilnych i internetowych, które nie są w stanie utrzymać poufności tajnego klucza klienta, dlatego istnieje potrzeba, aby token był wysyłany przez sam serwer uwierzytelniania. Jest to mniej bezpieczne i zaleca się, aby serwer był ustawiony na odmowę niejawnego przepływu wywołania użycia interfejsu API i zezwalania na to tylko dla aplikacji opartych na przeglądarce i na telefonie komórkowym.

hybrydowe przepływu: OAuth 2,0 przepływu, w którym

  • kodu autoryzacyjnego jest zwracany z odpowiedzialnego końcowego,
  • Niektóre znaczniki zwrócony bezpośrednio z zezwolenia końcowego, a pozostałe są zwracane (jako drugi etap, w zamian za kod autoryzacji) z punktu końcowego tokenu.
  • Używane tam, gdzie potrzebne są oba strumienie.