"use strict"; const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0]; const {useMDXComponents: _provideComponents} = arguments[0]; const headings = [{ "data": { "id": "wprowadzenie", "hProperties": { "id": "wprowadzenie" } }, "depth": 2, "value": "Wprowadzenie" }, { "data": { "id": "oauth-20-vs-openid-connect", "hProperties": { "id": "oauth-20-vs-openid-connect" } }, "depth": 2, "value": "OAuth 2.0 vs. OpenID Connect" }, { "data": { "id": "oauth-20", "hProperties": { "id": "oauth-20" } }, "depth": 3, "value": "OAuth 2.0" }, { "data": { "id": "openid-connect-oidc", "hProperties": { "id": "openid-connect-oidc" } }, "depth": 3, "value": "OpenID Connect (OIDC)" }, { "data": { "id": "typy-aplikacji", "hProperties": { "id": "typy-aplikacji" } }, "depth": 2, "value": "Typy aplikacji" }, { "data": { "id": "aplikacje-webowe-uruchomione-na-serwerze", "hProperties": { "id": "aplikacje-webowe-uruchomione-na-serwerze" } }, "depth": 3, "value": "Aplikacje webowe uruchomione na serwerze" }, { "data": { "id": "aplikacje-jednostronicowe-spa", "hProperties": { "id": "aplikacje-jednostronicowe-spa" } }, "depth": 3, "value": "Aplikacje jednostronicowe (SPA)" }, { "data": { "id": "aplikacje-mobilne", "hProperties": { "id": "aplikacje-mobilne" } }, "depth": 3, "value": "Aplikacje mobilne" }, { "data": { "id": "aplikacje-maszyna-do-maszyny-m2m", "hProperties": { "id": "aplikacje-maszyna-do-maszyny-m2m" } }, "depth": 3, "value": "Aplikacje maszyna-do-maszyny (M2M)" }, { "data": { "id": "aplikacje-działające-na-urządzeniach-iot", "hProperties": { "id": "aplikacje-działające-na-urządzeniach-iot" } }, "depth": 3, "value": "Aplikacje działające na urządzeniach IoT" }, { "data": { "id": "chroń-swoje-api", "hProperties": { "id": "chroń-swoje-api" } }, "depth": 2, "value": "Chroń swoje API" }, { "data": { "id": "projektowanie-autoryzacji", "hProperties": { "id": "projektowanie-autoryzacji" } }, "depth": 3, "value": "Projektowanie autoryzacji" }, { "data": { "id": "tokeny-dostępu", "hProperties": { "id": "tokeny-dostępu" } }, "depth": 3, "value": "Tokeny dostępu" }, { "data": { "id": "wskaźniki-zasobów", "hProperties": { "id": "wskaźniki-zasobów" } }, "depth": 3, "value": "Wskaźniki zasobów" }, { "data": { "id": "połącz-to-wszystko", "hProperties": { "id": "połącz-to-wszystko" } }, "depth": 2, "value": "Połącz to wszystko" }, { "data": { "id": "zakończenie", "hProperties": { "id": "zakończenie" } }, "depth": 2, "value": "Zakończenie" }]; const readingTime = { "minutes": 11, "words": 3270, "text": "11 min read" }; const frontmatter = undefined; function _createMdxContent(props) { const _components = { a: "a", blockquote: "blockquote", code: "code", h2: "h2", h3: "h3", li: "li", ol: "ol", p: "p", pre: "pre", span: "span", strong: "strong", ul: "ul", ..._provideComponents(), ...props.components }, {LogtoCloudButton} = _components; if (!LogtoCloudButton) _missingMdxReference("LogtoCloudButton", true); return _jsxs(_Fragment, { children: [_jsxs(_components.h2, { id: "wprowadzenie", children: ["Wprowadzenie", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#wprowadzenie", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Aplikacje chmurowe to obecnie trend. Choć typ aplikacji może się różnić (web, mobilne, desktopowe itp.), wszystkie mają zaplecze chmurowe zapewniające usługi takie jak przechowywanie, obliczenia i bazy danych. Zazwyczaj te aplikacje muszą uwierzytelnić użytkowników i nadać im uprawnienia do dostępu do określonych zasobów." }), "\n", _jsx(_components.p, { children: "Choć możliwe są własnoręcznie skonstruowane mechanizmy uwierzytelniania i autoryzacji, bezpieczeństwo stało się jednym z głównych priorytetów podczas tworzenia aplikacji chmurowych. Na szczęście nasza branża ma sprawdzone standardy, takie jak OAuth 2.0 i OpenID Connect, które pomagają nam w implementacji bezpiecznego uwierzytelniania i autoryzacji." }), "\n", _jsx(_components.p, { children: "Ten post zakłada następujące:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Masz podstawową wiedzę na temat tworzenia aplikacji (web, mobilnych lub innego typu)." }), "\n", _jsx(_components.li, { children: "Słyszałeś o koncepcjach uwierzytelniania i autoryzacji." }), "\n", _jsxs(_components.li, { children: ["Słyszałeś o ", _jsx(_components.a, { href: "https://auth.wiki/oauth-2.0", children: "OAuth 2.0" }), " i ", _jsx(_components.a, { href: "https://auth.wiki/openid-connect", children: "OpenID Connect" }), "."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Tak, \"słyszałeś\" wystarcza dla punktów 2 i 3. Ten post używa przykładów z rzeczywistego świata do wyjaśnienia koncepcji i ilustrowania procesu za pomocą diagramów. Zaczynajmy!" }), "\n", _jsxs(_components.h2, { id: "oauth-20-vs-openid-connect", children: ["OAuth 2.0 vs. OpenID Connect", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oauth-20-vs-openid-connect", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Jeśli znasz już OAuth 2.0 i OpenID Connect, możesz kontynuować czytanie, ponieważ omówimy tu pewne rzeczywiste przykłady. Jeśli te standardy są dla ciebie nowe, również jest bezpiecznie kontynuować, gdyż wprowadzimy je w prosty sposób." }), "\n", _jsxs(_components.h3, { id: "oauth-20", children: ["OAuth 2.0", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oauth-20", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: [_jsx(_components.a, { href: "https://auth.wiki/oauth-2.0", children: "OAuth 2.0" }), " to framework autoryzacji, który pozwala aplikacji uzyskać ograniczony dostęp do chronionych zasobów w innej aplikacji w imieniu użytkownika lub samej aplikacji. Większość popularnych usług, takich jak Google, Facebook i GitHub, używa OAuth 2.0 do logowania społecznościowego (np. \"Zaloguj się za pomocą Google\")."] }), "\n", _jsx(_components.p, { children: "Na przykład masz aplikację webową MyApp, która chce uzyskać dostęp do Google Drive użytkownika. Zamiast prosić użytkownika o udostępnienie swoich danych uwierzytelniających Google Drive, MyApp może użyć OAuth 2.0 do zażądania dostępu do Google Drive w imieniu użytkownika. Oto uproszczony przepływ:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Otwórz MyApp i
kliknij \"Połącz Google Drive\"\n MyApp->>Google: Przekieruj do Google\n Google->>User: Zaloguj się do Google\n User->>Google: Zaloguj się\n Google->>User: Poproś o zgodę
na dostęp do Google Drive\n User->>Google: Przyznaj dostęp do MyApp\n Google->>MyApp: Przekieruj do MyApp
z danymi autoryzacji (np. tokenem dostępu)\n MyApp->>Google: Uzyskaj dostęp do Google Drive użytkownika\n" }) }), "\n", _jsxs(_components.p, { children: ["W tym przepływie, MyApp nigdy nie widzi danych uwierzytelniających Google Drive użytkownika. Zamiast tego otrzymuje ", _jsx(_components.a, { href: "https://auth.wiki/access-token", children: "token dostępu" }), " od Google, który pozwala mu na dostęp do Google Drive w imieniu użytkownika."] }), "\n", _jsxs(_components.p, { children: ["W terminologii OAuth 2.0, MyApp jest ", _jsx(_components.a, { href: "https://auth.wiki/client", children: "klientem" }), ", Google jest zarówno ", _jsx(_components.a, { href: "https://auth.wiki/authorization-server", children: "serwerem autoryzacji" }), ", jak i ", _jsx(_components.a, { href: "https://auth.wiki/resource-server", children: "serwerem zasobów" }), " dla prostoty. W rzeczywistości często mamy oddzielne serwery autoryzacji i zasobów, aby oferować doświadczenie pojedynczego logowania (SSO). Na przykład, Google jest serwerem autoryzacji i może mieć wiele serwerów zasobów, takich jak Google Drive, Gmail i YouTube."] }), "\n", _jsx(_components.p, { children: "Należy zauważyć, że rzeczywisty przepływ autoryzacji jest bardziej złożony niż ten. OAuth 2.0 ma różne typy grantów, zakresy i inne koncepcje, o których powinieneś wiedzieć. Zostawmy to na chwilę i przejdźmy do OpenID Connect." }), "\n", _jsxs(_components.h3, { id: "openid-connect-oidc", children: ["OpenID Connect (OIDC)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#openid-connect-oidc", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["OAuth 2.0 jest świetny do autoryzacji, ale możesz zauważyć, że nie ma sposobu na identyfikację użytkownika (czyli uwierzytelnianie). ", _jsx(_components.a, { href: "https://auth.wiki/openid-connect", children: "OpenID Connect" }), " to warstwa tożsamości na szczycie OAuth 2.0, która dodaje możliwości uwierzytelniania."] }), "\n", _jsx(_components.p, { children: "W powyższym przykładzie, MyApp musi wiedzieć, kim jest użytkownik, zanim rozpocznie przepływ autoryzacji. Zauważ, że tutaj zaangażowani są dwaj użytkownicy: użytkownik MyApp i użytkownik Google Drive. W tym przypadku, MyApp musi poznać użytkownika własnej aplikacji." }), "\n", _jsx(_components.p, { children: "Spójrzmy na prosty przykład, zakładając, że użytkownicy mogą zalogować się do MyApp używając nazwy użytkownika i hasła:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant IdP as Dostawca Tożsamości (IdP)\n\n User->>MyApp: Otwórz MyApp i
kliknij \"Zaloguj się\"\n MyApp->>IdP: Przekieruj do IdP\n IdP->>User: Poproś o nazwę użytkownika i hasło\n User->>IdP: Wpisz nazwę użytkownika i hasło\n IdP->>IdP: Uwierzytelnij użytkownika\n IdP->>MyApp: Przekieruj do MyApp
z danymi uwierzytelnienia i
autoryzacji (np. tokenem ID)\n MyApp->>User: Wyświetl profil użytkownika
(przez token ID lub punkt końcowy userinfo)\n" }) }), "\n", _jsxs(_components.p, { children: ["Ponieważ uwierzytelniamy użytkownika naszej własnej aplikacji, zazwyczaj nie ma potrzeby prosić o zgodę tak, jak to zrobił Google w przepływie OAuth 2.0. Tymczasem potrzebujemy czegoś, co potrafi zidentyfikować użytkownika. OpenID Connect wprowadza koncepcje, takie jak ", _jsx(_components.strong, { children: "token ID" }), " i ", _jsx(_components.strong, { children: "punkt końcowy userinfo" }), ", które nam w tym pomogą."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Możesz zauważyć, że ", _jsx(_components.strong, { children: _jsx(_components.a, { href: "https://auth.wiki/identity-provider", children: "dostawca tożsamości (IdP)" }) }), " jest nowym, samodzielnym uczestnikiem w przepływie. Jest to samo, co ", _jsx(_components.strong, { children: "serwer autoryzacji" }), " w OAuth 2.0, ale dla lepszej klarowności, używamy terminu IdP, aby pokazać, że jest odpowiedzialny za uwierzytelnianie użytkowników i zarządzanie tożsamościami."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Kiedy twój biznes rośnie, możesz mieć wiele aplikacji, które dzielą tę samą bazę użytkowników. Podobnie jak OAuth 2.0, OpenID Connect pozwala mieć jeden serwer autoryzacji, który potrafi uwierzytelnić użytkowników dla wielu aplikacji. Jeśli użytkownik jest już zalogowany w jednej aplikacji, nie musi ponownie wpisywać swoich danych uwierzytelniających, gdy inna aplikacja przekierowuje go do IdP. Przepływ może być przeprowadzony automatycznie bez interakcji użytkownika. To się nazywa pojedyncze logowanie (SSO)." }), "\n", _jsx(_components.p, { children: "Ponownie, jest to mocno uproszczony przepływ i pod maską jest jeszcze więcej szczegółów. Na razie przejdźmy do następnej sekcji, aby zapobiec przeciążeniu informacyjnemu." }), "\n", _jsxs(_components.h2, { id: "typy-aplikacji", children: ["Typy aplikacji", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#typy-aplikacji", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["W poprzedniej sekcji użyliśmy aplikacji webowych jako przykładów, podczas gdy świat jest bardziej różnorodny. Dla dostawcy tożsamości, dokładny język programowania, framework czy platforma, której używasz, nie mają tak naprawdę znaczenia. W praktyce jedną istotną różnicą jest to, czy aplikacja jest ", _jsx(_components.a, { href: "https://auth.wiki/client#public-clients", children: "klientem publicznym" }), " czy ", _jsx(_components.a, { href: "https://auth.wiki/client#private-clients", children: "klientem prywatnym (zaufanym)" }), ":"] }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Klient publiczny" }), ": klient, który nie może utrzymać swoich danych uwierzytelniających w tajemnicy, co oznacza, że właściciel zasobu (użytkownik) ma do nich dostęp. Na przykład aplikacja webowa uruchamiana w przeglądarce (np. aplikacja jednostronicowa)."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Klient prywatny" }), ": klient, który jest w stanie utrzymać swoje dane uwierzytelniające w tajemnicy bez ich ujawniania użytkownikom (właścicielom zasobu). Na przykład aplikacja webowa uruchamiana na serwerze (np. aplikacja webowa po stronie serwera) lub usługa API."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Mając to na uwadze, zobaczmy, jak OAuth 2.0 i OpenID Connect mogą być używane w różnych typach aplikacji." }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsx(_components.p, { children: "\"Aplikacja\" i \"klient\" mogą być używane zamiennie w kontekście tego posta." }), "\n"] }), "\n", _jsxs(_components.h3, { id: "aplikacje-webowe-uruchomione-na-serwerze", children: ["Aplikacje webowe uruchomione na serwerze", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplikacje-webowe-uruchomione-na-serwerze", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Aplikacja działa na serwerze i dostarcza strony HTML użytkownikom. Wiele popularnych frameworków webowych, takich jak Express.js, Django i Ruby on Rails, zalicza się do tej kategorii; a frameworki typu backend-for-frontend (BFF), jak Next.js i Nuxt.js, również są uwzględnione. Te aplikacje mają następujące cechy:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Ponieważ serwer pozwala tylko na prywatny dostęp (użytkownicy publiczni nie mają dostępu do kodu ani danych uwierzytelniających serwera), uważa się go za klienta prywatnego." }), "\n", _jsx(_components.li, { children: "Ogólny przepływ uwierzytelniania użytkownika jest taki sam jak ten, którego omówiliśmy w sekcji \"OpenID Connect\"." }), "\n", _jsx(_components.li, { children: "Aplikacja może używać tokenu ID wydanego przez dostawcę tożsamości (tj. dostawcę OpenID Connect) do identyfikacji użytkownika i wyświetlania treści specyficznych dla użytkownika." }), "\n", _jsxs(_components.li, { children: ["Aby utrzymać aplikację w bezpieczeństwie, aplikacja zazwyczaj używa ", _jsx(_components.strong, { children: "przepływu autoryzacji kodu" }), " do uwierzytelniania użytkownika i uzyskiwania tokenów."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Tymczasem aplikacja może potrzebować dostępu do innych wewnętrznych usług API w architekturze mikroserwisów; lub jest to aplikacja monolityczna, która potrzebuje kontrolę dostępu dla różnych części aplikacji. Omówimy to w sekcji \"Chroń swoje API\"." }), "\n", _jsxs(_components.h3, { id: "aplikacje-jednostronicowe-spa", children: ["Aplikacje jednostronicowe (SPA)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplikacje-jednostronicowe-spa", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Aplikacja działa w przeglądarce użytkownika i komunikuje się z serwerem za pomocą API. React, Angular i Vue.js to popularne frameworki do tworzenia SPA. Te aplikacje mają następujące cechy:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Ponieważ kod aplikacji jest widoczny dla publiczności, uważa się go za klienta publicznego." }), "\n", _jsx(_components.li, { children: "Ogólny przepływ uwierzytelniania użytkownika jest taki sam jak ten, którego omówiliśmy w sekcji \"OpenID Connect\"." }), "\n", _jsx(_components.li, { children: "Aplikacja może używać tokenu ID wydanego przez dostawcę tożsamości (tj. dostawcę OpenID Connect) do identyfikacji użytkownika i wyświetlania treści specyficznych dla użytkownika." }), "\n", _jsxs(_components.li, { children: ["Aby utrzymać aplikację w bezpieczeństwie, aplikacja zazwyczaj używa ", _jsx(_components.strong, { children: "przepływu autoryzacji kodu z PKCE (Proof Key for Code Exchange)" }), " do uwierzytelniania użytkownika i uzyskiwania tokenów."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Zazwyczaj SPA potrzebują dostępu do innych usług API do pobierania i aktualizowania danych. Omówimy to w sekcji \"Chroń swoje API\"." }), "\n", _jsxs(_components.h3, { id: "aplikacje-mobilne", children: ["Aplikacje mobilne", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplikacje-mobilne", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Aplikacja działa na urządzeniu mobilnym (iOS, Android itp.) i komunikuje się z serwerem za pomocą API. W większości przypadków te aplikacje mają te same cechy co SPA." }), "\n", _jsxs(_components.h3, { id: "aplikacje-maszyna-do-maszyny-m2m", children: ["Aplikacje maszyna-do-maszyny (M2M)", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplikacje-maszyna-do-maszyny-m2m", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: [_jsx(_components.a, { href: "https://auth.wiki/machine-to-machine", children: "Aplikacje maszyna-do-maszyny" }), " to ", _jsx(_components.a, { href: "https://auth.wiki/client", children: "klienci" }), ", które działają na serwerze (maszyna) i komunikują się z innymi serwerami. Te aplikacje mają następujące cechy:"] }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "Podobnie jak aplikacje webowe uruchomione na serwerze, aplikacje M2M są klientami prywatnymi." }), "\n", _jsx(_components.li, { children: "Aplikacja może nie potrzebować identyfikacji użytkownika; zamiast tego musi uwierzytelnić się, aby uzyskać dostęp do innych usług." }), "\n", _jsx(_components.li, { children: "Aplikacja może używać tokenu dostępu wydanego przez dostawcę tożsamości (tj. dostawcę OAuth 2.0) do uzyskania dostępu do innych usług." }), "\n", _jsxs(_components.li, { children: ["Aby utrzymać aplikację w bezpieczeństwie, aplikacja zazwyczaj używa ", _jsx(_components.strong, { children: "przepływu danych uwierzytelniających klienta" }), " do uzyskiwania tokenów dostępu."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Podczas uzyskiwania dostępu do innych usług, aplikacja może potrzebować dostarczyć token dostępu w nagłówku żądania. Omówimy to w sekcji \"Chroń swoje API\"." }), "\n", _jsxs(_components.h3, { id: "aplikacje-działające-na-urządzeniach-iot", children: ["Aplikacje działające na urządzeniach IoT", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#aplikacje-działające-na-urządzeniach-iot", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "Aplikacja działa na urządzeniu IoT (np. urządzeniach inteligentnego domu, nosidłach itp.) i komunikuje się z serwerem za pomocą API. Te aplikacje mają następujące cechy:" }), "\n", _jsxs(_components.ol, { children: ["\n", _jsx(_components.li, { children: "W zależności od możliwości urządzenia może to być klient publiczny lub prywatny." }), "\n", _jsx(_components.li, { children: "Ogólny przepływ uwierzytelniania może różnić się od tego, o którym mówiliśmy w sekcji \"OpenID Connect\" w zależności od możliwości urządzenia. Na przykład niektóre urządzenia mogą nie posiadać ekranu umożliwiającego użytkownikom wpisanie swoich danych uwierzytelniających." }), "\n", _jsx(_components.li, { children: "Jeśli urządzenie nie potrzebuje identyfikacji użytkownika, może nie potrzebować używać tokenów ID ani punktów końcowych userinfo; zamiast tego może być traktowane jako aplikacja maszyna-do-maszyny (M2M)." }), "\n", _jsxs(_components.li, { children: ["Aby utrzymać aplikację w bezpieczeństwie, aplikacja może używać ", _jsx(_components.strong, { children: "przepływu autoryzacji kodu z PKCE (Proof Key for Code Exchange)" }), " do uwierzytelniania użytkownika i uzyskiwania tokenów lub ", _jsx(_components.strong, { children: "przepływu danych uwierzytelniających klienta" }), " do uzyskiwania tokenów dostępu."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Podczas komunikacji z serwerem urządzenie może potrzebować dostarczyć token dostępu w nagłówku żądania. Omówimy to w sekcji \"Chroń swoje API\"." }), "\n", _jsxs(_components.h2, { id: "chroń-swoje-api", children: ["Chroń swoje API", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#chroń-swoje-api", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Dzięki OpenID Connect, możliwe jest identyfikowanie użytkownika i pobieranie danych specyficznych dla użytkownika za pomocą ", _jsx(_components.a, { href: "https://auth.wiki/id-token", children: "tokenów ID" }), " lub ", _jsx(_components.a, { href: "https://auth.wiki/userinfo-endpoint", children: "punktów końcowych userinfo" }), ". Proces ten nazywa się uwierzytelnianiem. Jednak prawdopodobnie nie chcesz, aby wszystkie twoje zasoby były dostępne dla wszystkich uwierzytelnionych użytkowników, na przykład tylko administratorzy mogą mieć dostęp do strony zarządzania użytkownikami."] }), "\n", _jsx(_components.p, { children: "Tutaj wchodzi w grę autoryzacja. Pamiętaj, że OAuth 2.0 to framework autoryzacji, a OpenID Connect to warstwa tożsamości na szczycie OAuth 2.0; co oznacza, że możesz również używać OAuth 2.0, gdy OpenID Connect jest już w miejscu." }), "\n", _jsxs(_components.p, { children: ["Przypomnijmy sobie przykład, którego użyliśmy w sekcji \"OAuth 2.0\": MyApp chce uzyskać dostęp do Google Drive użytkownika. Nie jest praktyczne pozwolić MyApp uzyskać dostęp do wszystkich plików użytkownika w Google Drive. Zamiast tego MyApp powinien jawnie zgłosić, co chce uzyskać (np. dostęp tylko do odczytu do plików w określonym folderze). W terminologii OAuth 2.0 nazywa się to ", _jsx(_components.strong, { children: "zakresem" }), "."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsx(_components.p, { children: "Możesz zobaczyć termin \"uprawnienie\" używany zamiennie z \"zakresem\" w kontekście OAuth 2.0, ponieważ czasami \"zakres\" jest niejednoznaczny dla użytkowników nietechnicznych." }), "\n"] }), "\n", _jsx(_components.p, { children: "Kiedy użytkownik przyznaje dostęp do MyApp, serwer autoryzacji wydaje token dostępu z zażądanym zakresem. Token dostępu jest następnie wysyłany do serwera zasobów (Google Drive), aby uzyskać dostęp do plików użytkownika." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Otwórz MyApp i
kliknij \"Połącz Google Drive\"\n MyApp->>Google: Przekieruj do Google\n Google->>User: MyApp chce uzyskać dostęp do twojego
Google Drive z zakresem \"tylko do odczytu\"\n User->>Google: Okej, przyznaj dostęp do MyApp\n Google->>MyApp: Przekieruj do MyApp
z danymi autoryzacji (np. tokenem dostępu)\n MyApp->>Google: Uzyskaj dostęp do Google Drive użytkownika
z tokenem dostępu i zakresem\n" }) }), "\n", _jsx(_components.p, { children: "Naturalnie, możemy zastąpić Google Drive naszymi własnymi usługami API. Na przykład MyApp musi uzyskać dostęp do OrderService, aby pobrać historię zamówień użytkownika. Tym razem, ponieważ uwierzytelnianie użytkownika jest już przeprowadzone przez dostawcę tożsamości i zarówno MyApp, jak i OrderService są pod naszą kontrolą, możemy pominąć prośbę do użytkownika o przyznanie dostępu; MyApp może bezpośrednio wysłać żądanie do OrderService z tokenem dostępu wydanym przez dostawcę tożsamości." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant OrderService\n\n User->>MyApp: Otwórz historię zamówień\n MyApp->>OrderService: Pobierz moją historię zamówień (z tokenem dostępu)\n OrderService->>MyApp: Zwróć historię zamówień\n MyApp->>User: Wyświetl historię zamówień\n" }) }), "\n", _jsxs(_components.p, { children: ["Token dostępu może zawierać ", _jsx(_components.code, { children: "read:order" }), " ", _jsx(_components.a, { href: "https://auth.wiki/scope", children: "zakres" }), ", aby wskazać, że użytkownik może odczytać swoją historię zamówień."] }), "\n", _jsxs(_components.p, { children: ["Załóżmy teraz, że użytkownik przypadkowo wpisuje URL strony administratora w przeglądarce. Ponieważ użytkownik nie jest administratorem, w tokenie dostępu nie ma ", _jsx(_components.code, { children: "admin" }), " zakresu. OrderService odrzuci żądanie i zwróci komunikat błędu."] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User\n participant MyApp\n participant OrderService\n\n User->>MyApp: Otwórz stronę administratora\n MyApp->>OrderService: Pobierz stronę administratora (z tokenem dostępu)\n OrderService->>MyApp: Błąd: Odmowa dostępu\n MyApp->>User: Wyświetl komunikat o błędzie\n" }) }), "\n", _jsx(_components.p, { children: "W tym przypadku OrderService może zwrócić kod statusu 403 Forbidden, aby wskazać, że użytkownik nie jest uprawniony do uzyskania dostępu do strony administratora." }), "\n", _jsx(_components.p, { children: "Dla aplikacji maszyna-do-maszyny (M2M), nie uczestniczy w tym procesie żaden użytkownik. Aplikacje mogą bezpośrednio zażądać tokenów dostępu od dostawcy tożsamości i użyć ich do uzyskania dostępu do innych usług. Ten sam koncept nadal ma zastosowanie: token dostępu zawiera odpowiednie zakresy dla uzyskania dostępu do zasobów." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant MyApp\n participant OrderService\n\n MyApp->>OrderService: Pobierz wszystkie zamówienia (z tokenem dostępu)\n OrderService->>MyApp: Zwróć wszystkie zamówienia\n" }) }), "\n", _jsxs(_components.h3, { id: "projektowanie-autoryzacji", children: ["Projektowanie autoryzacji", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#projektowanie-autoryzacji", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Widać dwie ważne rzeczy do rozważenia przy projektowaniu ", _jsx(_components.a, { href: "https://auth.wiki/authorization", children: "autoryzacji" }), " do ochrony twoich usług API:"] }), "\n", _jsxs(_components.ol, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Zakresy" }), ": Definiowanie, do czego klient ma dostęp. Zakresy mogą być drobnoziarniste (np. ", _jsx(_components.code, { children: "read:order" }), ", ", _jsx(_components.code, { children: "write:order" }), ") lub bardziej ogólne (np. ", _jsx(_components.code, { children: "order" }), ") w zależności od twoich wymagań."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Kontrola dostępu" }), ": Definiowanie, kto może mieć poszczególne zakresy. Na przykład, tylko administratorzy mogą mieć ", _jsx(_components.code, { children: "admin" }), " zakres."] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["Jeśli chodzi o ", _jsx(_components.a, { href: "https://auth.wiki/access-control", children: "kontrolę dostępu" }), ", popularne podejścia to:"] }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Kontrola dostępu oparta na rolach (RBAC)" }), ": Przydzielanie ról użytkownikom i definiowanie, jakie role mają dostęp do jakich zasobów. Na przykład, rola administratora może mieć dostęp do strony administratora."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "Kontrola dostępu oparta na atrybutach (ABAC)" }), ": Definiowanie zasad opartych na atrybutach (np. dział użytkownika, lokalizacja itp.) i podejmowanie decyzji o kontroli dostępu w oparciu o te atrybuty. Na przykład, użytkownik z działu \"Inżynieria\" może mieć dostęp do strony inżynieryjnej."] }), "\n"] }), "\n", _jsx(_components.p, { children: "Warto wspomnieć, że dla obu podejść standardowym sposobem weryfikacji kontroli dostępu jest sprawdzanie zakresów tokenu dostępu, zamiast ról czy atrybutów. Role i atrybuty mogą być bardzo dynamiczne, a zakresy są bardziej statyczne, co znacznie ułatwia zarządzanie." }), "\n", _jsxs(_components.p, { children: ["Dla szczegółowych informacji na temat kontroli dostępu, możesz odnieść się do ", _jsx(_components.a, { href: "https://blog.logto.io/rbac-and-abac", children: "RBAC i ABAC: Modele kontroli dostępu, które powinieneś znać" }), "."] }), "\n", _jsxs(_components.h3, { id: "tokeny-dostępu", children: ["Tokeny dostępu", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#tokeny-dostępu", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Chociaż wiele razy wspominaliśmy o terminie \"", _jsx(_components.a, { href: "https://auth.wiki/access-token", children: "token dostępu" }), "\", nie omówiliśmy jak go uzyskać. W OAuth 2.0 token dostępu jest wydawany przez serwer autoryzacji (dostawcę tożsamości) po pomyślnym zakończeniu przepływu autoryzacji."] }), "\n", _jsx(_components.p, { children: "Przyjrzyjmy się bliżej przykładzie z Google Drive i załóżmy, że używamy przepływu kodu autoryzacji:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant User\n participant MyApp\n participant Google\n\n User->>MyApp: Otwórz MyApp i
kliknij \"Połącz Google Drive\"\n MyApp->>Google: Przekieruj do Google\n Google->>User: Zaloguj się do Google\n User->>Google: Zaloguj się\n Google->>User: Poproś o zgodę
na dostęp do Google Drive\n User->>Google: Przyznaj dostęp do MyApp\n Google->>MyApp: Przekieruj do MyApp
z danymi autoryzacji (np. kodem autoryzacji)\n MyApp->>Google: Użyj kodu autoryzacji do
wymiany na token dostępu\n Google->>MyApp: Zwróć token dostępu\n MyApp->>Google: Uzyskaj dostęp do Google Drive użytkownika z tokenem dostępu\n" }) }), "\n", _jsx(_components.p, { children: "Istnieją ważne kroki w przepływie dotyczącym wydawania tokenu dostępu:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: ["Krok 2 (Przekieruj do Google): MyApp przekierowuje użytkownika do Google z ", _jsx(_components.strong, { children: "żądaniem autoryzacji" }), ". Zazwyczaj to żądanie zawiera następujące informacje:", "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: "Który klient (MyApp) inicjuje żądanie" }), "\n", _jsx(_components.li, { children: "Jakie zakresy MyApp żąda" }), "\n", _jsx(_components.li, { children: "Gdzie Google powinien przekierować użytkownika po zakończeniu autoryzacji" }), "\n"] }), "\n"] }), "\n", _jsxs(_components.li, { children: ["Krok 5 (Poproś o zgodę na dostęp do Google Drive): Google prosi użytkownika o przyznanie dostępu do MyApp. Użytkownik może zdecydować się na przyznanie lub odmowę dostępu. Ten krok nazywa się ", _jsx(_components.strong, { children: "zgodą" }), "."] }), "\n", _jsxs(_components.li, { children: ["Krok 7 (Przekieruj do MyApp z danymi autoryzacji): Ten krok został nowo wprowadzony w diagramie. Zamiast bezpośrednio zwracać token dostępu, Google zwraca jednorazowy ", _jsx(_components.strong, { children: "kod autoryzacji" }), " do MyApp dla bardziej bezpiecznej wymiany. Kod ten jest używany do uzyskania tokenu dostępu."] }), "\n", _jsxs(_components.li, { children: ["Krok 8 (Użyj kodu autoryzacji do wymiany na token dostępu): To również nowy krok. MyApp wysyła kod autoryzacji do Google, aby wymienić go na token dostępu. Jako dostawca tożsamości, Google złoży kontekst żądania i zdecyduje, czy wydać token dostępu:", "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: "Klient (MyApp) jest tym, za kogo się podaje" }), "\n", _jsx(_components.li, { children: "Użytkownik przyznał dostęp klientowi" }), "\n", _jsx(_components.li, { children: "Użytkownik jest tym, za kogo się podaje" }), "\n", _jsx(_components.li, { children: "Użytkownik ma niezbędne zakresy" }), "\n", _jsx(_components.li, { children: "Kod autoryzacji jest ważny i nie wygasł" }), "\n"] }), "\n"] }), "\n"] }), "\n", _jsx(_components.p, { children: "Powyższy przykład zakłada, że serwer autoryzacji (dostawca tożsamości) i serwer zasobów to to samo (Google). Jeśli są one rozdzielone, biorąc przykład MyApp i OrderService, przepływ będzie wyglądał tak:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant User\n participant MyApp\n participant IdP as Dostawca tożsamości (IdP)\n participant OrderService\n\n User->>MyApp: Otwórz MyApp i
kliknij \"Zaloguj się\"\n MyApp->>IdP: Przekieruj do IdP\n IdP->>User: Poproś o nazwę użytkownika i hasło\n User->>IdP: Wpisz nazwę użytkownika i hasło\n IdP->>IdP: Uwierzytelnij użytkownika\n IdP->>MyApp: Przekieruj do MyApp
z danymi autoryzacji (np. kodem autoryzacji)\n MyApp->>IdP: Użyj kodu autoryzacji do
wymiany na tokeny (token ID, token dostępu)\n IdP->>MyApp: Zwróć tokeny\n MyApp->>OrderService: Pobierz moją historię zamówień (z tokenem dostępu)\n OrderService->>OrderService: Zweryfikuj token dostępu\n OrderService->>MyApp: Zwróć historię zamówień\n" }) }), "\n", _jsx(_components.p, { children: "W tym przepływie serwer autoryzacji (IdP) wydaje zarówno token ID, jak i token dostępu do MyApp (krok 8). Token ID jest używany do identyfikacji użytkownika, a token dostępu jest używany do uzyskania dostępu do innych usług, takich jak OrderService. Ponieważ zarówno MyApp, jak i OrderService są usługami pierwszej strony, zazwyczaj nie proszą użytkownika o przyznanie dostępu; zamiast tego polegają na kontroli dostępu w dostawcy tożsamości, aby stwierdzić, czy użytkownik może uzyskać dostęp do zasobów (tj. czy token dostępu zawiera niezbędne zakresy)." }), "\n", _jsx(_components.p, { children: "Na koniec przyjrzyjmy się, jak token dostępu jest używany w aplikacjach maszyna-do-maszyny (M2M). Ponieważ w procesie nie uczestniczy żaden użytkownik, a aplikacja jest zaufana, może bezpośrednio zażądać tokenu dostępu od dostawcy tożsamości:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n autonumber\n participant MyApp\n participant IdP as Dostawca tożsamości (IdP)\n participant OrderService\n\n MyApp->>IdP: Zażądaj tokenu dostępu\n IdP->>MyApp: Zwróć token dostępu\n MyApp->>OrderService: Pobierz wszystkie zamówienia (z tokenem dostępu)\n OrderService->>OrderService: Zweryfikuj token dostępu\n OrderService->>MyApp: Zwróć wszystkie zamówienia\n" }) }), "\n", _jsx(_components.p, { children: "Kontrola dostępu może nadal być tutaj stosowana. Dla OrderService nie ma znaczenia, kim jest użytkownik ani która aplikacja żąda danych; ważne jest tylko token dostępu i zakresy, które zawiera." }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Tokeny dostępu są zazwyczaj kodowane jako JSON Web Tokens (JWT). Aby dowiedzieć się więcej o JWT, możesz odnieść się do ", _jsx(_components.a, { href: "https://blog.logto.io/what-is-jwt", children: "Co to jest JSON Web Token (JWT)?" }), "."] }), "\n"] }), "\n", _jsxs(_components.h3, { id: "wskaźniki-zasobów", children: ["Wskaźniki zasobów", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#wskaźniki-zasobów", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "OAuth 2.0 wprowadza koncepcję zakresów dla kontroli dostępu. Jednak możesz szybko zauważyć, że zakresy nie są wystarczające:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: ["OpenID Connect definiuje zestaw standardowych zakresów, takich jak ", _jsx(_components.code, { children: "openid" }), ", ", _jsx(_components.code, { children: "offline_access" }), " i ", _jsx(_components.code, { children: "profile" }), ". Może być mylące mieszanie tych standardowych zakresów z własnymi zakresami."] }), "\n", _jsx(_components.li, { children: "Możesz mieć wiele usług API, które dzielą tę samą nazwę zakresu, ale mają różne znaczenia." }), "\n"] }), "\n", _jsxs(_components.p, { children: ["Jednym z powszechnych rozwiązań jest dodawanie sufiksów (lub prefiksów) do nazw zakresu, aby wskazać zasób (usługę API). Na przykład, ", _jsx(_components.code, { children: "read:order" }), " i ", _jsx(_components.code, { children: "read:product" }), " są bardziej jasne niż ", _jsx(_components.code, { children: "read" }), " i ", _jsx(_components.code, { children: "read" }), ". Rozszerzenie OAuth 2.0 ", _jsx(_components.a, { href: "https://tools.ietf.org/html/rfc8707", children: "RFC 8707" }), " wprowadza nowy parametr ", _jsx(_components.code, { children: "resource" }), ", aby wskazać ", _jsx(_components.strong, { children: "serwer zasobów" }), ", do którego klient chce uzyskać dostęp."] }), "\n", _jsxs(_components.p, { children: ["W rzeczywistości, usługi API są zazwyczaj definiowane za pomocą URL, więc bardziej naturalne jest używanie URL jako ", _jsx(_components.a, { href: "https://auth.wiki/resource-indicator", children: "wskaźników zasobów" }), ". Na przykład, API OrderService może być reprezentowane jako:"] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { children: "https://api.example.com/orders\n" }) }), "\n", _jsxs(_components.p, { children: ["Jak widzisz, parametr ten przynosi wygodę używania rzeczywistych URL zasobów w żądaniach autoryzacyjnych i tokenach dostępu. Warto wspomnieć, że RFC 8707 może nie być zaimplementowane przez wszystkich dostawców tożsamości. Powinieneś sprawdzić dokumentację swojego dostawcy tożsamości, aby zobaczyć, czy obsługuje parametr ", _jsx(_components.code, { children: "resource" }), " (Logto go obsługuje)."] }), "\n", _jsxs(_components.p, { children: ["W skrócie, parametr ", _jsx(_components.code, { children: "resource" }), " może być używany w żądaniach autoryzacyjnych i tokenach dostępu, aby wskazać zasób, do którego klient chce uzyskać dostęp."] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsxs(_components.p, { children: ["Nie ma żadnych ograniczeń dotyczących dostępności wskaźników zasobów, tj. wskaźnik zasobów nie musi być rzeczywistym URL, który wskazuje na usługę API. Dlatego nazwa \"wskaźnik zasobów\" odpowiednio odzwierciedla jego rolę w procesie autoryzacji. Możesz używać wirtualnych URL do reprezentowania zasobów, które chcesz chronić. Na przykład, możesz zdefiniować wirtualny URL ", _jsx(_components.code, { children: "https://api.example.com/admin" }), " w swojej aplikacji monolitycznej, aby reprezentować zasób, do którego dostęp mogą mieć tylko administratorzy."] }), "\n"] }), "\n", _jsxs(_components.h2, { id: "połącz-to-wszystko", children: ["Połącz to wszystko", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#połącz-to-wszystko", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "W tym momencie omówiliśmy podstawy OAuth 2.0 i OpenID Connect, oraz jak ich używać w różnych typach aplikacji i scenariuszach. Choć omówiliśmy je oddzielnie, możesz je łączyć zgodnie z wymaganiami biznesowymi. Ogólna architektura może być tak prosta jak ta:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "flowchart LR\n MyApp --- IdP\n" }) }), "\n", _jsx(_components.p, { children: "Albo nieco bardziej skomplikowana:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "flowchart LR\n WA[Aplikacja webowa] --- IdP[Dostawca tożsamości]\n MA[Aplikacja mobilna] --- IdP\n OS[OrderService] --- IdP\n AS[AdminService] --- IdP\n WA --- OS\n MA --- OS\n SA[Aplikacja jednostronicowa] --- IdP\n SA --- AS\n OS --- AS\n" }) }), "\n", _jsx(_components.p, { children: "Gdy twoja aplikacja rośnie, zauważysz, że dostawca tożsamości (IdP) odgrywa kluczową rolę w architekturze; ale nie wiąże się bezpośrednio z celami biznesowymi. Choć świetnym pomysłem jest przesiadanie go na zaufanego dostawcę, musimy mądrze wybierać dostawcę tożsamości. Dobry dostawca tożsamości może znacznie upraszczać proces, redukować wysiłek programistyczny i chronić przed potencjalnymi pułapkami związanymi z bezpieczeństwem." }), "\n", _jsxs(_components.h2, { id: "zakończenie", children: ["Zakończenie", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#zakończenie", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["Dla nowoczesnych aplikacji chmurowych, dostawca tożsamości (lub serwer autoryzacji) jest centralnym miejscem dla ", _jsx(_components.a, { href: "https://auth.wiki/authentication", children: "uwierzytelniania" }), " użytkowników, ", _jsx(_components.a, { href: "https://auth.wiki/iam", children: "zarządzania tożsamością" }), ", oraz ", _jsx(_components.a, { href: "https://auth.wiki/access-control", children: "kontroli dostępu" }), ". Choć omówiliśmy wiele koncepcji w tym poście, wciąż istnieje wiele niuansów do uwzględnienia przy implementacji takiego systemu. Jeśli jesteś zainteresowany dalszym pogłębianiem wiedzy, możesz przeglądać naszego bloga w poszukiwaniu bardziej szczegółowych artykułów."] }), "\n", _jsx(LogtoCloudButton, {})] }); } function MDXContent(props = {}) { const {wrapper: MDXLayout} = { ..._provideComponents(), ...props.components }; return MDXLayout ? _jsx(MDXLayout, { ...props, children: _jsx(_createMdxContent, { ...props }) }) : _createMdxContent(props); } return { headings, readingTime, frontmatter, default: MDXContent }; function _missingMdxReference(id, component) { throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it."); }