Jaki jest cel typu niejawnej autoryzacji dotacji w OAuth 2?

Nie wiem, czy mam po prostu jakiś martwy punkt lub coś, ale przeczytałem specyfikację OAuth 2 wiele razy i przejrzałem archiwa listy mailingowej, i muszę jeszcze znaleźć dobre wyjaśnienie, dlaczego Implicit Grant opracowano przepływ w celu uzyskania tokenów dostępu. W porównaniu do przyznania kodu autoryzacji wydaje się, że po prostu rezygnuje z uwierzytelniania klienta bez bardzo ważnego powodu. Jak to jest „zoptymalizowane dla klientów zaimplementowanych w przeglądarce za pomocą języka skryptowego” (cytując specyfikację)?

Oba przepływy zaczynają się tak samo (źródło: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

1. Klient inicjuje przepływ, kierując klienta użytkownika agenta właściciela zasobu do punktu końcowego autoryzacji.
2. Serwer autoryzacji uwierzytelnia właściciela zasobu (za pośrednictwem klienta użytkownika) i ustala, czy właściciel zasobu przyznaje, czy odrzuca żądanie dostępu klienta.
3. Zakładając, że właściciel zasobu przyznaje dostęp, serwer autoryzacji przekierowuje klienta użytkownika z powrotem do klienta za pomocą podanego wcześniej identyfikatora URI przekierowania (w żądaniu lub podczas rejestracji klienta).
   • Identyfikator URI przekierowania zawiera kod autoryzacji (przepływ kodu autoryzacji)
   • Identyfikator URI przekierowania zawiera token dostępu we fragmencie URI (przepływ niejawny)

Oto, gdzie przepływy się rozdzielają. W obu przypadkach identyfikator URI przekierowania w tym punkcie znajduje się w punkcie końcowym hostowanym przez klienta:

• W przepływie kodu autoryzacji, gdy agent użytkownika trafi w ten punkt końcowy kodem autoryzacji w identyfikatorze URI, kod w tym punkcie końcowym wymienia kod autoryzacji wraz z poświadczeniami klienta na token dostępu, którego może następnie użyć w razie potrzeby. Może na przykład zapisać go na stronie internetowej, do której skrypt na stronie mógłby uzyskać dostęp.
• Przepływ niejawny całkowicie pomija ten etap uwierzytelniania klienta i po prostu ładuje stronę internetową ze skryptem klienta. Tutaj jest urocza sztuczka z fragmentem adresu URL, który zapobiega zbyt dużemu przekazywaniu tokenu dostępu, ale wynik końcowy jest zasadniczo taki sam: witryna hostowana przez klienta wyświetla stronę z jakimś skryptem, który może pobrać token dostępu .
  

Stąd moje pytanie: co tu uzyskano, pomijając etap uwierzytelniania klienta?

Oto moje przemyślenia:

Celem kodu autoryzacji + tokena w przepływie kodu autoryzacji jest to, że token i klucz tajny klienta nigdy nie zostaną ujawnione właścicielowi zasobu, ponieważ podróżują między serwerami.

Z drugiej strony, niejawny przepływ dotacji dotyczy klientów, które są w całości zaimplementowane przy użyciu javascript i działają w przeglądarce właściciela zasobu. Aby korzystać z tego przepływu, nie potrzebujesz kodu po stronie serwera. Następnie, jeśli wszystko dzieje się w przeglądarce właściciela zasobu, nie ma już sensu wydawania kodu uwierzytelniającego i tajnego klienta, ponieważ token i tajny klient nadal będą udostępniane właścicielowi zasobu. Dołączenie kodu uwierzytelniającego i tajnego klucza klienta sprawia, że ​​przepływ jest bardziej złożony bez dodawania prawdziwych zabezpieczeń.

Więc odpowiedź na „co zostało zdobyte?” to „prostota”.

Jest tam ze względów bezpieczeństwa, a nie dla uproszczenia.

Należy wziąć pod uwagę różnicę między klientem użytkownika a klientem :

User-agent to oprogramowanie, za pomocą którego użytkownik („właściciel zasobów”) komunikuje się z innymi częściami systemu (serwerem uwierzytelniania i serwerem zasobów).

Klient to oprogramowanie, które chce uzyskać dostęp do zasobów użytkownika na serwerze zasobów.

W przypadku oddzielonego klienta użytkownika i klienta uzasadnione jest przyznanie kodu autoryzacyjnego . Np. Użytkownik korzysta z przeglądarki internetowej (user-agent), aby zalogować się na swoje konto Facebook na Kickstarter. W tym przypadku klient jest jednym z serwerów Kickstarter, który obsługuje loginy użytkownika. Ten serwer otrzymuje token dostępu i token odświeżania z Facebooka. Zatem ten typ klienta uważany za „bezpieczny”, z powodu ograniczonego dostępu, tokeny można zapisać, a Kickstarter może uzyskać dostęp do zasobów użytkowników, a nawet odświeżyć tokeny dostępu bez interakcji użytkownika.

Jeśli klient użytkownika i klient są połączone (np. Natywna aplikacja mobilna, aplikacja javascript), można zastosować przepływ pracy niejawnej autoryzacji . Opiera się na obecności właściciela zasobu (do wprowadzania poświadczeń) i nie obsługuje tokenów odświeżania. Jeśli ten klient przechowuje token dostępu do późniejszego wykorzystania, będzie to stanowić problem bezpieczeństwa, ponieważ token może być łatwo wyodrębniony przez inne aplikacje lub użytkowników klienta. Brak tokena odświeżania jest dodatkową wskazówką, że ta metoda nie jest przeznaczona do uzyskiwania dostępu do zasobów użytkownika pod nieobecność użytkownika.

Zazwyczaj tłumaczy się, że dotacja niejawna jest łatwiejsza do wdrożenia, gdy używasz klienta JavaScript. Ale myślę, że to niewłaściwy sposób na to spojrzeć. Jeśli używasz klienta JavaScript, który żąda chronionych zasobów bezpośrednio za pośrednictwem XMLHttpRequest, niejawna dotacja jest twoją jedyną opcją, chociaż jest mniej bezpieczna. *

Przyznanie kodu autoryzacji zapewnia dodatkowe bezpieczeństwo, ale działa tylko wtedy, gdy serwer WWW żąda chronionych zasobów. Ponieważ serwer WWW może przechowywać token dostępu, istnieje mniejsze ryzyko, że token dostępu zostanie wystawiony na działanie Internetu, i możesz wydać token, który będzie trwał długo. A ponieważ serwer WWW jest zaufany, można mu nadać „token odświeżania”, aby mógł otrzymać nowy token dostępu po wygaśnięciu starego.

Ale - i jest to kwestia, którą łatwo przeoczyć - bezpieczeństwo przepływu kodu autoryzacji działa tylko wtedy, gdy serwer WWW jest chroniony sesją, która jest ustalana za pomocą uwierzytelnienia użytkownika (logowania). Bez sesji niezaufany użytkownik mógłby po prostu wysyłać żądania do serwera WWW, używając client_id, i byłoby to tak samo, jakby użytkownik miał token dostępu. Dodanie sesji oznacza, że ​​tylko uwierzytelniony użytkownik może uzyskać dostęp do chronionych zasobów. ID_klienta to tylko „tożsamość” aplikacji internetowej JS, a nie uwierzytelnianie tej aplikacji internetowej.

Oznacza to również, że możesz zakończyć sesję przed wygaśnięciem tokena OAuth. Nie ma standardowego sposobu unieważnienia tokena dostępu. Ale jeśli twoja sesja wygasa, token dostępu jest bezużyteczny, ponieważ nikt o tym nie wie poza serwerem WWW. Jeśli niezaufany użytkownik uzyska dostęp do klucza sesji, będzie mógł uzyskać dostęp do chronionych zasobów tylko przez czas trwania sesji.

Jeśli nie ma serwera WWW, musisz skorzystać z Implicit grant. Oznacza to jednak, że token dostępu jest narażony na działanie Internetu. Jeśli niezaufany użytkownik uzyska do niego dostęp, może z niego korzystać do momentu wygaśnięcia. Oznacza to, że będą mieli do niego dostęp dłużej niż w przypadku przyznania kodu autoryzacyjnego. Dlatego warto rozważyć wcześniejsze wygaśnięcie tokena i unikanie udostępniania bardziej wrażliwych zasobów.

* EDYCJA: Niedawno ludzie zalecają unikanie korzystania z grantu niejawnego, nawet w aplikacjach internetowych bez serwera. Zamiast tego możesz użyć przydziału kodu autoryzacyjnego skonfigurowanego z pustym kluczem tajnym wraz z PKCE. Udzielenie kodu autoryzacyjnego pozwala na przechowywanie tokena dostępowego w historii przeglądarki, a PKCE zapobiega ujawnieniu go, jeśli ktoś przejmie przekierowanie URL w celu kradzieży kodu autoryzacyjnego. W takim przypadku potrzebujesz serwera, aby uniknąć zwrotu tokenu odświeżania, ponieważ Twój klient prawdopodobnie nie może go bezpiecznie przechowywać. I powinien wydać token dostępu z tymi samymi ograniczeniami, o których mowa powyżej.

Sprowadza się to do: Jeśli użytkownik uruchamia przeglądarkę lub „publiczną” (JavaScript) aplikację internetową bez komponentu po stronie serwera, to użytkownik domyślnie ufa aplikacji (i przeglądarce, w której działa, potencjalnie z inną przeglądarką oparte na aplikacjach ...).

Nie ma zewnętrznego serwera zdalnego, tylko serwer zasobów. Kod autoryzacyjny nie ma żadnej korzyści, ponieważ nie ma innego agenta oprócz przeglądarki działającej w imieniu użytkownika. Z tego samego powodu nie ma korzyści z poświadczeń klienta. ( Każdy klient może próbować użyć tego przepływu).

Wpływ na bezpieczeństwo jest jednak znaczący. From http://tools.ietf.org/html/rfc6749#section-10.3 :

Podczas korzystania z niejawnego typu przyznania token dostępu jest przesyłany we fragmencie URI, który może udostępnić go nieautoryzowanym podmiotom.

From http://tools.ietf.org/html/rfc6749#section-10.16 :

Właściciel zasobu może dobrowolnie przekazać dostęp do zasobu, przyznając token dostępu złośliwemu klientowi atakującego. Może to być spowodowane phishingiem lub innym pretekstem ...

Nie jestem pewien, czy dobrze rozumiem odpowiedź i komentarz Dana. Wydaje mi się, że w odpowiedzi podano pewne fakty poprawne, ale dokładnie wskazuje to, o co poprosił OP. Jeśli dobrze rozumiem, główną zaletą niejawnego przepływu grantów jest to, że klient taki jak aplikacja JS (np. Rozszerzenie Chrome) nie musi ujawniać tajnego klienta.

Dan Taflin powiedział:

... w przepływie kodu autoryzacyjnego właściciel zasobu nigdy nie musi widzieć tokena dostępu, podczas gdy w klientach javascript jest to nieuniknione. Tajny klient nadal może być przechowywany przed klientami javascript przy użyciu przepływu kodu autoryzacji, jednak ..

Być może źle cię zrozumiałem, ale klient (w tym przypadku aplikacja JS) musi przekazać poświadczenie klienta (klucz klienta i klucz tajny) do serwera zasobów w przepływie kodu autoryzacji, prawda? Tajnego klienta nie można „ukryć przed JS”.

Chociaż Implicit Grant został zaprojektowany do obsługi aplikacji, które nie mogły chronić tajemnicy klienta, w tym aplikacji JavaScript po stronie klienta, niektórzy dostawcy wdrażają alternatywę za pomocą kodu autoryzacji bez klucza tajnego klienta. OAuth 2.0 IETF RFC-6749 został opublikowany w 2012 r., A aktualne zalecenia dotyczą niektórych ostatnich dyskusji z 2017 r.

Dyskusje 2017 na temat listy mailingowej IETF OAuth są dostępne u tych implementatorów:

• Czerwony kapelusz: https://www.ietf.org/.../oauth/current/msg16966.html
• Deutsche Telekom: https://www.ietf.org/.../oauth/current/msg16968.html
• Smart Health IT: https://www.ietf.org/.../oauth/current/msg16967.html

Przeczytaj więcej tutaj:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Uproszczony był wcześniej zalecany klientom bez tajemnicy, ale został zastąpiony przy użyciu przyznania kodu autoryzacyjnego bez tajemnicy.

...

Wcześniej zalecano, aby aplikacje przeglądarkowe korzystały z przepływu „niejawnego”, który natychmiast zwraca token dostępu i nie ma kroku wymiany tokenu. W czasie, gdy specyfikacja została pierwotnie napisana, najlepsza praktyka branżowa uległa zmianie, aby zalecać stosowanie kodu autoryzacji bez klucza tajnego klienta. Daje to więcej możliwości stworzenia bezpiecznego przepływu, na przykład przy użyciu parametru stanu. Referencje: Redhat , Deutsche Telekom , Smart Health IT .

W przypadku aplikacji mobilnych wspomniano także o przejściu na kod uwierzytelniający bez tajnego klucza klienta od Implicit Grant:

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

oprócz innych odpowiedzi ważne jest również, aby zdawać sobie sprawę, że profil niejawny umożliwia przepływ tylko w kanale frontowym, w przeciwieństwie do przepływu kodu autoryzacji, który wymaga oddzwonienia do serwera autoryzacji; staje się to widoczne w OpenID Connect, który jest protokołem SSO zbudowanym na Auth 2.0, gdzie przepływ niejawny przypomina dość popularne powiązanie SAML POST, a przepływ kodu autoryzacji przypomina mniej rozpowszechnione wiązanie artefaktu SAML

W domyślnym przepływie, jeśli przeglądarka użytkownika jest uszkodzona (złe rozszerzenie / wirus), wówczas korupcja uzyskuje dostęp do zasobów użytkownika i może zrobić złe rzeczy.

W przepływie autoryzacji korupcja nie może, ponieważ nie zna tajemnicy klienta.

https://tools.ietf.org/html/rfc6749#page-8

Domniemany

Domniemana dotacja to uproszczony przepływ kodu autoryzacji zoptymalizowany dla klientów zaimplementowanych w przeglądarce przy użyciu języka skryptowego, takiego jak JavaScript. W ramach przepływu niejawnego zamiast wydawania klientowi kodu autoryzacji klient otrzymuje bezpośrednio token dostępu (w wyniku autoryzacji właściciela zasobu). Rodzaj grantu jest niejawny, ponieważ nie są wydawane pośrednie poświadczenia (takie jak kod autoryzacji) (a następnie wykorzystywane do uzyskania tokena dostępu).

Wydając token dostępu podczas niejawnego przepływu grantu,
serwer autoryzacji nie uwierzytelnia klienta. W niektórych
przypadkach tożsamość klienta można zweryfikować za pomocą identyfikatora URI przekierowania
używanego do dostarczenia tokena dostępu do klienta. Token dostępu może być udostępniony właścicielowi zasobu lub innym aplikacjom z dostępem do klienta użytkownika właściciela zasobu.

Ujawnione granty poprawiają szybkość reakcji i wydajność niektórych
klientów (takich jak klient zaimplementowany jako aplikacja w przeglądarce),
ponieważ zmniejszają liczbę podróży w obie strony wymaganych do uzyskania
tokena dostępu.

Myślę, że Will Cain odpowiedział na to, mówiąc: „Nie ma korzyści z poświadczeń klienta z tego samego powodu. (Każdy klient może próbować użyć tego przepływu.)” Weź również pod uwagę, że redirect_uri dla niejawnego przepływu może być „localhost” - bez oddzwaniania jest wykonany z serwera autoryzacji dla niejawnego przepływu. Ponieważ nie ma możliwości wcześniejszego zaufania klientowi, użytkownik musiałby zatwierdzić zwolnienie roszczeń użytkownika.

Implicit Grant pozwala uzyskać tokeny z punktu końcowego autoryzacji za pomocą GET. Oznacza to, że serwer autoryzacji nie musi obsługiwać CORS.

Jeśli nie stanowi to problemu i nie ma innych problemów związanych z serwerem autoryzacji, które byłyby nieelastyczne (np. Tokeny odświeżania z jakiegoś powodu nie są opcjonalne), wówczas przepływ kodu autoryzacji jest preferowany, nawet dla klientów publicznych, zgodnie z najnowszymi trendami w branży i przynajmniej w tym (obecnym) przypadku oficjalnego projektu .

Historycznie istniały inne powody, aby wdrożyć domniemany przepływ, ale wydaje się, że obecnie przeważają nad nimi korzyści bezpieczeństwa wynikające z przyznania kodu autoryzacji, w tym:

• opcja dostarczania i używania tokenów przez kanał zwrotny dla poufnych klientów
• nieujawnianie tokenów w historii przeglądarki dla klientów publicznych
• przerywanie nieautoryzowanego przepływu przed wydaniem tokenów - w PKCE , dla „wszystkich klientów OAuth”

Właśnie natknąłem się na artykuł o OAuth 2.0. Autor stwierdza, że ​​przyczyną niejawnego przepływu jest to, że aplikacje JS były tam bardzo ograniczone:

jeśli zastanawiasz się, dlaczego niejawny typ został zawarty w OAuth 2.0, wyjaśnienie jest proste: Polityka Same Origin. Wówczas aplikacje frontendowe nie mogły wysyłać żądań do różnych hostów w celu uzyskania tokena dostępu za pomocą kodu. Dzisiaj mamy CORS (udostępnianie zasobów między źródłami).

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611