Jaki jest cel typu niejawnej autoryzacji dotacji w OAuth 2?

254

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?

Dan Taflin
źródło
Spójrz na to: ibm.com/developerworks/wikis/display/…
Håvard Geithus
5
Link w poprzednim komentarzu jest martwy. Oto zaktualizowany
AndrewR
3
Przeczytałem tutaj wszystkie odpowiedzi, ale nadal nie rozumiem, jak nie można wymagać od prywatnego klienta tajnego uzyskania tokena dostępu. Powiedzmy, że TrustedAppDeveloper wydaje TrustedPopularApp, który pozwala użytkownikom na przyznanie mu uprawnień (powiedzmy za pomocą Twittera oauth) przy użyciu domniemanej dotacji. Jeśli jestem EvilAppDeveloper, co mnie powstrzyma przed stworzeniem aplikacji, która przekazuje TrustedPopularAppId jako identyfikator klienta w domniemanym wniosku o przyznanie grantu, a następnie wykonywania działań (takich jak spamowanie kanału) w imieniu użytkownika, które teraz wyglądają, jakby pochodziły od TrustedPopularApp ?
adevine
Zastanawiam się nad tym samym co adevine. Ale najprawdopodobniej aplikacje wymagające domniemanego wniosku o grant nie potrzebują więcej uwierzytelnienia, ponieważ wszystkie są pobierane?
Mave
13
@adevine Tym, co uniemożliwiłoby EvilApp w twoim scenariuszu uwierzytelnienia na Twitterze jako TrustedPopularApp jest to, że nie mógł odbierać wywołań zwrotnych z Twittera, zawsze byłyby wysyłane do identyfikatora URI zdefiniowanego podczas rejestracji identyfikatora klienta
Ivan

Odpowiedzi:

196

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”.

Philip Peshin
źródło
4
Dzięki. To dobrze, że w przepływie kodu autoryzacyjnego właściciel zasobów 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 za pomocą przepływu kodu autoryzacji: jednak po uwierzytelnieniu i uzyskaniu tokena dostępu kod po stronie serwera przekaże token klientowi javascript. Teraz widzę jednak, że niejawny przepływ grantów umożliwia dystrybucję javascript oauth SDK, takich jak Facebook, uwalniając programistów od konieczności całkowitego pisania własnego kodu.
Dan Taflin,
3
Chciałbym dodać, że przepływ kodu autoryzacji umożliwia klientom przechowywanie tokenów i ponowne ich użycie. W domniemanym przepływie nie zawsze masz tę opcję i jako taki, domniemany przepływ jest pragmatycznym wyborem między poziomem bezpieczeństwa a wygodą.
PålOliver
2
To tylko połowa odpowiedzi i „co zostało utracone”?
EralpB
3
Nie sądzę, że jest to wyczerpująca odpowiedź, niejawny przepływ nie ma na celu uzyskania przewagi nad prostotą, ale narazić na szwank obawy związane z bezpieczeństwem aplikacji po stronie klienta. Auth code, wraz z client_idi client_secretsą używane do identyfikowania zaufanych klientów, którzy mogą odświeżyć tokeny do długiego logowania i do „logowania offline” . Jednak w aplikacji po stronie klienta, nie ma sposobu, aby zarejestrować każdego klienta, stąd „uproszczone” niejawny typu dotacja dla tymczasowego dostępu do informacji o użytkowniku
Chen Xie
1
Dołączenie tajnego klucza klienta nie tylko sprawia, że ​​przepływ jest bardziej złożony, ale również mniej bezpieczny . Tajemnica klienta nie jest tajemnicą, jeśli musi być wyliczona w kodzie klienta, a zatem byłaby narażona na działanie Internetu. Jeśli identyfikator klienta jest używany tylko w przepływach niejawnych, nie stanowi to problemu. Ale jeśli jest on również używany gdzie indziej na twojej platformie do odświeżania tokenu lub kodu autoryzacyjnego, to ujawnienie odpowiedniego tajnego klucza jest dużym problemem.
Ataraxia,
94

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.

artkoenig
źródło
2
Widzę, że moja przeglądarka loguje się na moje konto Google od miesięcy. Czy Google używa tokena dostępu w przeglądarce lub tokena dostępu z długim terminem ważności? jaka różnica w użyciu między tokenem dostępu z długim czasem ważności a tokenem dostępu? każdy inny klient może złapać token dostępu i użyć go, gdy nie ma właściciela zasobu.
Mohammad Nikravan,
Zakładam, że masz na myśli różnicę między tokenem odświeżania a tokenem dostępu o długim czasie ważności ? Token odświeżania nie powinien być zapisywany w niepewnych scenariuszach, ale możesz jednak zapisać token dostępu (np. W lokalnej pamięci przeglądarki). Bezpieczeństwo osiąga się, utrzymując żywotność tokena dostępowego na jak najniższym poziomie, ale nadal wygodnym dla użytkowników (np. Możesz wylogować je automatycznie po x minutach bezczynności). Jeśli korzystasz z tokenów dostępu o długiej żywotności, praktycznie przestajesz używać tokenów odświeżania.
artkoenig
Dziękuję za wyjaśnienie, ale mam też inne zamieszanie. Nie rozumiem, dlaczego potrzebujemy przepływu „Kod autoryzacyjny”. Możemy osiągnąć ten sam wynik na serwerze przez niejawny przepływ (access_token) i token odświeżania. Wygląda na to, że jedynym aspektem bezpieczeństwa niejawnego przepływu jest to, że kod dostępu powinien mieć krótką żywotność, więc nie można go używać na serwerach. OK, ale token odświeżania rozwiązuje ten problem. Dlaczego powinniśmy korzystać z przepływu auth_code i żądać tokena dostępu przez ten token na serwerze, aby uzyskać kod dostępu, skoro możemy osiągnąć ten sam wynik za pomocą odświeżania tokena?
Mohammad Nikravan
„token można łatwo pobrać z innych aplikacji” Jak?
mvmn
@MohammadNikravan poszukaj odpowiedzi w stackoverflow.com/q/13387698/355438
Lu55
60

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.

JW.
źródło
21

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 ...

Będzie
źródło
co rozumiesz przez „publiczną”, (JavaScript) aplikację internetową bez komponentu po stronie serwera? Jak może istnieć aplikacja internetowa bez serwera?
Zammy Page
2
@ZammyPage, jest to często tak zwana aplikacja pojedynczej strony (SPA). Cała aplikacja jest obsługiwana z zasobu statycznego. Javascript w aplikacji następnie dynamicznie uzyskuje dostęp do wszystkich potrzebnych zasobów, na dowolnych serwerach zasobów, do których może uzyskać dostęp. Nie ma serwera, który generuje zawartość klienta: javascript w kliencie modyfikuje DOM w miarę potrzeby, aby reprezentować zasoby, do których miał dostęp.
Elroy Flynn
13

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”.

tzuchien.chiu
źródło
6
Zdaję sobie sprawę, że to stare pytanie, ale jest to lepsza odpowiedź niż zaakceptowana. Przyczyną istnienia Implicit Grant jest to, że klient javascript nie może zachować tajemnicy, a zatem nie może zostać uwierzytelniony. Tak więc dla bezpieczeństwa serwer autoryzacji musi polegać wyłącznie na rejestracji przekierowania uri i kliencie użytkownika. Tokeny autoryzacji przekazujesz tylko do agenta użytkownika i tylko w określonym uri przekierowania, teoretycznie zapobiegając przechwyceniu (ponieważ złośliwy użytkownik, który nie jest właścicielem domeny przekierowującego uri, nie może wykonać kodu w kliencie użytkownika w tym uri).
gregates,
Rzeczywiście zaakceptowana odpowiedź wprawiła mnie w zakłopotanie. Sprawiło, że pomyślałem, że źle zrozumiałem, czym jest sekret_klienta! Ta odpowiedź i powyższy komentarz są na miejscu.
Sarsaparilla,
9

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:

Przeczytaj więcej tutaj:

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:

Grokify
źródło
Myślę, że chcesz być ostrożny z tym zaleceniem. Jest to zalecane w poradniku dla aplikacji natywnych, a nie spa. Niestety nie ma dobrych wskazówek na temat SPA, co zostało udokumentowane w wielu internetowych dyskusjach, forach, a nawet oauth-wg listy mailingowej.
Tom
Zalecenie przejścia na kod uwierzytelniający bez tajnego klucza od domniemanego przyznania jest zaleceniem zarówno dla OSO, jak i aplikacji mobilnych, ale mój powyższy fragment dotyczy OSO. W artykule, o którym mowa, używa się podobnego tekstu zarówno w przypadku OSO, jak i aplikacji mobilnych, ale z odpowiednim językiem w języku „aplikacje oparte na przeglądarce”, „aplikacjach mobilnych i natywnych”. Również odniesienia do Redhat, DT, Smart Health IT są specyficzne dla OSO i nie zostały uwzględnione w uwadze dotyczącej aplikacji mobilnych. W odpowiedzi dodałem głęboki link do SPA, aby ułatwić znalezienie. Proszę zamieścić kilka linków do wspomnianych dyskusji.
Grokify
Dość niedawną (2018) dyskusję oauth-wg można znaleźć tutaj ietf.org/mail-archive/web/oauth/current/msg18020.html . RFC 8252 jest dla aplikacji natywnych, jak sugeruje tytuł „OAuth 2.0 dla aplikacji natywnych”. Odniesienia do Redhat, DT, Smart Health IT to odpowiedzi na dyskusję o liście mailowej, a nie rfc, robocza wersja robocza itp.
Tom
3

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

Hans Z.
źródło
3

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.

Tempo
źródło
2

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.

Rzv Razvan
źródło
1

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.

Mike Schwartz
źródło
1

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”
ko la
źródło
0

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

Lu55
źródło