Jakie są różnice między jawnymi a poufnymi klientami?

Kiedy używasz Logto do tworzenia aplikacji, zauważysz, że istnieje kilka różnych typów aplikacji do wyboru, w tym aplikacja jednostronicowa (SPA), aplikacja natywna i tradycyjna aplikacja webowa. Intuicyjnie, z nazwy wynika, że aplikacja natywna działa na systemach operacyjnych powszechnie spotykanych na urządzeniach takich jak telefony. Ale czym dokładnie są SPA i tradycyjna aplikacja webowa? Dlaczego musimy odróżniać te różne typy aplikacji? Ten artykuł ujawnia odpowiedzi na te pytania.

Zanim zaczniemy, musimy krótko przedstawić pewne pojęcia.

Co to jest OAuth?#

OAuth jest otwartym standardem dotyczącym delegacji dostępu, który jest zazwyczaj używany jako sposób przyznawania stronom internetowym lub aplikacjom dostępu do ich informacji na innych witrynach bez udostępniania swoich haseł przez użytkowników internetu.

W ostatniej dekadzie stopniowo stał się standardowym procesem autoryzacji i został szeroko zaakceptowany przez większość firm, takich jak Google, Meta, Microsoft i inne. Obecnie używana wersja to OAuth 2.0.

W kontekście OAuth aplikacja, o której wcześniej wspomnieliśmy, jest nazywana Klientem. Mogą one składać wnioski o zasoby chronione, pod warunkiem uzyskania autoryzacji właściciela zasobu (zazwyczaj użytkowników końcowych).

Jawni klienci i poufni klienci#

OAuth definiuje dwa typy klientów, na podstawie ich zdolności do utrzymania poufności poświadczeń klienta.

Poufny klient#

Klient, który jest zdolny do utrzymania poufności swoich poświadczeń (na przykład klient wdrożony na bezpiecznym serwerze z ograniczonym dostępem do poświadczeń klienta) lub taki, który jest zdolny do bezpiecznej autoryzacji klienta poprzez inne środki.

Jawny klient#

Klient, który nie jest zdolny do utrzymania poufności swoich poświadczeń (na przykład klient działający na urządzeniu właściciela zasobu, takim jak aplikacja natywna czy aplikacja webowa) i nie może również bezpiecznie uwierzytelnić się jako klient poprzez inne środki.

SPA, aplikacja natywna i tradycyjna aplikacja webowa#

Dzięki powyższej wiedzy podstawowej, przyjrzyjmy się, co oznaczają SPA, aplikacja natywna i tradycyjna aplikacja webowa w kontekście Logto, a także czy są one uważane za jawnymi czy poufnymi klientami.

SPA#

Kod po stronie klienta SPA jest pobierany z serwera WWW i wykonywany w agencie użytkownika (takim jak przeglądarka internetowa) właściciela zasobu na jego urządzeniu. Dane protokołu i poświadczenia są łatwo dostępne (i często widoczne) dla właściciela zasobu.

Aplikacja natywna#

Aplikacja natywna jest zainstalowana i wykonywana na urządzeniu właściciela zasobu. Dane protokołu i poświadczenia są dostępne dla właściciela zasobu. Zwykle zakłada się, że wszelkie poświadczenia uwierzytelniające klienta zawarte w aplikacji mogą być wydobyte.

Tradycyjna aplikacja webowa#

Tradycyjna aplikacja webowa to klient, który działa na serwerze WWW. Właściciel zasobu uzyskuje dostęp do klienta poprzez interfejs użytkownika HTML przedstawiany w agencie użytkownika na jego urządzeniu. Poświadczenia klienta, a także wszelkie tokeny dostępu wydane klientowi, są przechowywane na serwerze WWW i nie są ujawniane ani dostępne dla właściciela zasobu.

Zatem widać wyraźnie, że SPA i aplikacja natywna to jawni klienci, podczas gdy tradycyjna aplikacja webowa to klient poufny.

Możesz zauważyć, że tworząc SPA lub aplikację natywną w Logto, nie ma sekretu aplikacji, podczas gdy tradycyjna aplikacja webowa ma zarówno ID aplikacji, jak i sekret aplikacji. Dzieje się tak, ponieważ tajemnica jawnego klienta nie może być zagwarantowana jako bezpieczna.

Jak działa klient w przepływie autoryzacji OAuth?#

Podczas tworzenia aplikacji OAuth pierwszym krokiem jest zarejestrowanie klienta u dostawcy usług OAuth. Rejestracja klienta obejmuje podanie szczegółów dotyczących aplikacji, takich jak jej nazwa i URI przekierowania. Następnie dostawca usług OAuth generuje ID klienta i sekret klienta, które są uznawane za poświadczenia aplikacji.

ID klienta jest uznawane za informację publiczną i jest udostępniane użytkownikowi podczas procesu OAuth. Zazwyczaj jest zawarte w URL autoryzacji i widoczne dla użytkowników końcowych.

Z drugiej strony, sekret klienta działa jako hasło dla aplikacji i musi być utrzymywany w tajemnicy. Jest używany w procesie OAuth do wymiany kodu autoryzacyjnego (zakładając, że jest przepływ kodu autoryzacyjnego) w celu uzyskania tokenu dostępu. Obecność sekretów klienta zapewnia, że tylko zarejestrowane aplikacje mogą dokonać wymiany tokenów dostępu.

Wprowadzenie Proof Key for Code Exchange (PKCE)#

Jak wcześniej wspomniano, tajemnice jawnych klientów nie mogą być zapewnione jako bezpieczne, a atakujący mogą uzyskać poświadczenia klienta i podszywać się pod klientów, aby uzyskać dostęp do chronionych zasobów, co jest nie do przyjęcia w każdej sytuacji.

PKCE (Proof Key for Code Exchange) rozwiązuje ten problem poprzez tymczasowe generowanie weryfikatora kodu na początku każdego przepływu autoryzacji, który jest przechowywany lokalnie i haszowany w celu wygenerowania wyzwania kodowego, który jest wysyłany do serwera autoryzacji. Weryfikator kodu jest ponownie wysyłany do serwera autoryzacji podczas wymiany tokenu dostępu. Serwer autoryzacji weryfikuje, czy weryfikator kodu i wyzwanie kodowe pasują, co zapewnia, że jawny klient nie został podszyty.

Weryfikator kodu w PKCE faktycznie działa jak dynamiczny sekret klienta. Jego bezpieczeństwo jest zapewnione przez nieodwracalność algorytmu haszującego.

Podsumowanie#

W tym artykule omówiliśmy pojęcia poufnych klientów i jawnych klientów w OAuth. Dowiedzieliśmy się, że poufni klienci mają zdolność do utrzymania tajemnic i bezpiecznego przechowywania informacji poufnych, podczas gdy jawni klienci tej zdolności nie posiadają. Przeanalizowaliśmy przykłady dwóch typów klientów, w tym tradycyjne aplikacje webowe, SPA i aplikacje natywne, w kontekście praktyk produktowych Logto.

Omówiliśmy również proces rejestracji klienta w OAuth i role ID klienta i sekretu klienta.

Ponadto stwierdziliśmy, że jawni klienci napotykają ograniczenia w bezpiecznym przechowywaniu tajemnic klienta. Aby przezwyciężyć to ograniczenie, wprowadziliśmy PKCE (Proof Key for Code Exchange), rozszerzenie OAuth, które pozwala jawnym klientom na bezpieczną wymianę kodów autoryzacyjnych bez potrzeby posiadania tajemnicy klienta.

Nasz produkt, Logto, to kompleksowe rozwiązanie CIAM, które stosuje najlepsze praktyki protokołów OAuth i OIDC, aby zapewnić bezpieczeństwo na każdym etapie, w tym przyjęcie stosowania PKCE do ochrony bezpieczeństwa jawnych klientów.