Wprowadzenie do Systemu CAS – Czym Jest i Dlaczego Jest Ważny?

Opublikowano przez

Wprowadzenie do Systemu CAS – Czym Jest i Dlaczego Jest Ważny?

W dzisiejszym świecie cyfrowym, gdzie użytkownicy regularnie korzystają z wielu aplikacji i serwisów online, wygoda dostępu oraz bezpieczeństwo stały się kluczowymi aspektami. Wyobraźmy sobie sytuację, w której musimy logować się do każdego systemu oddzielnie, wpisując te same dane uwierzytelniające dziesiątki razy dziennie. Jest to nie tylko irytujące, ale także zwiększa ryzyko błędów i osłabia ogólne bezpieczeństwo, zmuszając użytkownika do zapamiętywania wielu haseł lub, co gorsza, używania tego samego hasła wszędzie. Tutaj z pomocą przychodzi Central Authentication Service, w skrócie CAS – otwarty protokół i jego implementacja, zaprojektowany z myślą o zapewnieniu pojedynczego logowania (Single Sign-On, SSO) dla aplikacji webowych.

CAS, często kojarzony z terminem CAS logowanie, to system uwierzytelniania, który pozwala użytkownikom na zalogowanie się raz do centralnego serwera, a następnie uzyskanie dostępu do wielu niezależnych aplikacji bez konieczności ponownego wprowadzania swoich danych. Jego głównym celem jest scentralizowanie procesu uwierzytelniania, odciążając aplikacje klienckie od konieczności zarządzania kontami użytkowników i zabezpieczania ich danych. Dzięki temu, aplikacje mogą skupić się na dostarczaniu swoich podstawowych funkcji, delegując odpowiedzialność za identyfikację użytkownika do zaufanego serwera CAS.

Protokół CAS został pierwotnie opracowany na Uniwersytecie Yale i szybko zyskał popularność, szczególnie w środowiskach akademickich, ale także w dużych przedsiębiorstwach i instytucjach rządowych. Jego siła tkwi w prostocie i efektywności. System CAS odgrywa kluczową rolę w poprawie user experience, znacząco redukując frustrację związaną z wielokrotnym logowaniem. Z punktu widzenia bezpieczeństwa, scentralizowany proces uwierzytelniania ułatwia implementację silnych polityk haseł, mechanizmów blokowania kont i integrację z bardziej zaawansowanymi metodami, takimi jak uwierzytelnianie dwuskładnikowe (MFA). To wszystko sprawia, że system CAS jest niezwykle ważnym elementem infrastruktury IT wielu organizacji.

Jak Działa CAS? Architektura i Kluczowe Komponenty Systemu

Zrozumienie, jak działa CAS logowanie, wymaga poznania jego architektury i interakcji między kluczowymi komponentami. Podstawowa idea jest taka, że serwer CAS działa jako zaufany pośrednik między użytkownikiem a aplikacjami, do których użytkownik chce uzyskać dostęp. Głównymi elementami w tym ekosystemie są:

  • Użytkownik (User Agent/Browser): Osoba próbująca uzyskać dostęp do chronionego zasobu.
  • Aplikacja Kliencka (Service Provider): Aplikacja webowa, która wymaga uwierzytelnienia użytkownika i która jest skonfigurowana do współpracy z serwerem CAS.
  • Serwer CAS (Central Authentication Service): Centralny punkt uwierzytelniania. To tutaj użytkownicy wprowadzają swoje dane logowania i to tutaj są one weryfikowane.

Proces przepływu uwierzytelniania w CAS jest zorganizowany wokół koncepcji „biletów”. Oto jak to działa krok po kroku:

  1. Żądanie dostępu: Użytkownik próbuje uzyskać dostęp do chronionego zasobu w aplikacji klienckiej (np. https://mojaaplikacja.pl/dashboard).
  2. Wykrycie braku uwierzytelnienia: Aplikacja kliencka, widząc, że użytkownik nie jest zalogowany, przekierowuje przeglądarkę użytkownika do serwera CAS (np. https://cas.mojafirma.pl/login?service=https://mojaaplikacja.pl/dashboard). W tym przekierowaniu zawarty jest adres zwrotny (parametr service), do którego użytkownik ma zostać odesłany po pomyślnym uwierzytelnieniu.
  3. Logowanie na serwerze CAS: Jeśli użytkownik nie ma aktywnej sesji CAS, serwer CAS wyświetla stronę logowania. Użytkownik wprowadza swoje dane (login i hasło).
  4. Weryfikacja danych: Serwer CAS weryfikuje dane użytkownika z podłączoną bazą danych (np. LDAP, Active Directory, baza SQL).
  5. Generowanie TGT (Ticket Granting Ticket): Po udanej weryfikacji, serwer CAS generuje unikalny token zwany Ticket Granting Ticket (TGT). TGT jest przechowywany w sesji przeglądarki użytkownika, zazwyczaj jako bezpieczny cookie. TGT reprezentuje aktywną sesję użytkownika z serwerem CAS i jest kluczowy dla Single Sign-On.
  6. Generowanie ST (Service Ticket): Serwer CAS generuje również unikalny Service Ticket (ST) dla konkretnej usługi, do której użytkownik próbował uzyskać dostęp. Jest to jednorazowy token.
  7. Przekierowanie z ST: Serwer CAS przekierowuje przeglądarkę użytkownika z powrotem do aplikacji klienckiej, dołączając Service Ticket w adresie URL (np. https://mojaaplikacja.pl/dashboard?ticket=ST-XYZ123ABC).
  8. Walidacja ST: Aplikacja kliencka odbiera Service Ticket i natychmiast wysyła go z powrotem do serwera CAS (zwykle za pośrednictwem żądania back-channel, czyli z serwera aplikacji do serwera CAS) w celu walidacji.
  9. Potwierdzenie użytkownika: Serwer CAS waliduje Service Ticket, sprawdza, czy został wydany dla tej konkretnej aplikacji i czy jest poprawny. W odpowiedzi (z powrotem do aplikacji klienckiej) wysyła potwierdzenie tożsamości użytkownika (np. jego login, atrybuty).
  10. Dostęp do zasobu: Po pomyślnej walidacji, aplikacja kliencka tworzy własną sesję dla użytkownika i udziela mu dostępu do żądanego zasobu.

Kluczowe dla działania SSO jest TGT. Gdy użytkownik próbuje uzyskać dostęp do innej aplikacji klienckiej (np. https://innafirma.pl/raporty), która również korzysta z tego samego serwera CAS, powtarza się kroki 1-2. Jednakże, ponieważ użytkownik posiada już TGT (z cookie), serwer CAS rozpoznaje jego aktywną sesję i od razu generuje nowy Service Ticket dla tej drugiej aplikacji, bez potrzeby ponownego wprowadzania danych logowania. To właśnie esencja pojedynczego logowania CAS.

Proces Logowania CAS Krok po Kroku – Perspektywa Użytkownika i Dewelopera

Zrozumienie mechanizmu CAS logowanie jest kluczowe zarówno dla końcowego użytkownika, który czerpie korzyści z płynnego dostępu, jak i dla dewelopera, który odpowiada za prawidłową implementację i integrację. Przyjrzyjmy się temu procesowi z obu perspektyw.

Perspektywa Użytkownika: Łatwość i Wygoda

Dla przeciętnego użytkownika, proces logowania CAS jest intuicyjny i ma na celu maksymalne uproszczenie dostępu do zasobów. Oto typowy scenariusz:

  1. Pierwszy kontakt z aplikacją: Użytkownik otwiera przeglądarkę i próbuje wejść na stronę chronioną przez CAS, na przykład: https://system-kadrowy.firma.pl.
  2. Automatyczne przekierowanie: Zamiast od razu zobaczyć system kadrowy, użytkownik zostaje automatycznie przekierowany na scentralizowaną stronę logowania CAS, która może wyglądać na przykład tak: https://cas.firma.pl/login?service=https://system-kadrowy.firma.pl.
  3. Wprowadzenie danych logowania: Na stronie CAS użytkownik widzi formularz, gdzie należy wprowadzić swoje unikalne dane – zazwyczaj login (np. adres e-mail, identyfikator pracownika) i hasło.
  4. Pomyślne uwierzytelnienie: Po poprawnym wprowadzeniu danych, użytkownik klika przycisk „Zaloguj” lub podobny. Serwer CAS weryfikuje te dane.
  5. Powrót do aplikacji: Jeśli dane są poprawne, użytkownik zostaje automatycznie przekierowany z powrotem do aplikacji kadrowej (https://system-kadrowy.firma.pl), do której teraz ma pełny dostęp.
  6. Dostęp do kolejnych aplikacji (SSO w działaniu): W ciągu tej samej sesji przeglądarki, użytkownik decyduje się otworzyć inną aplikację, np. system CRM: https://crm.firma.pl. CAS rozpoznaje, że użytkownik jest już zalogowany (dzięki TGT w sesji przeglądarki). Zamiast ponownie prosić o dane, użytkownik zostaje błyskawicznie przekierowany przez serwer CAS i od razu uzyskuje dostęp do systemu CRM, bez konieczności ponownego logowania. To właśnie istota logowania CAS w kontekście pojedynczego logowania.

Z perspektywy użytkownika, proces jest płynny, szybki i wymaga zapamiętania tylko jednego zestawu danych logowania dla wielu serwisów.

Perspektywa Dewelopera: Integracja i Konfiguracja

Dla deweloperów, integracja aplikacji z systemem CAS logowanie oznacza delegowanie odpowiedzialności za uwierzytelnianie i skupienie się na logice biznesowej. Oto kluczowe kroki i aspekty:

  1. Wybór biblioteki klienckiej CAS: Większość języków programowania i frameworków (Java, Python, PHP, Ruby on Rails, Node.js) posiada gotowe biblioteki klienckie CAS (np. Jasig CAS Client dla Javy, python-cas, phpCAS). Biblioteki te upraszczają komunikację z serwerem CAS.
  2. Konfiguracja aplikacji klienckiej:
    • Adres serwera CAS: Aplikacja musi wiedzieć, gdzie znajduje się serwer CAS, np. https://cas.firma.pl.
    • Adres zwrotny (Service URL): Aplikacja musi zdefiniować swój własny, unikalny adres (URL), który będzie używany jako parametr service w przekierowaniach do serwera CAS. Ten adres musi być zarejestrowany na serwerze CAS. Na przykład: https://system-kadrowy.firma.pl/cas-login.
    • Punkty końcowe walidacji: Biblioteka kliencka skonfiguruje punkty końcowe serwera CAS do walidacji biletów (np. /serviceValidate, /proxyValidate).
  3. Rejestracja usług na serwerze CAS: Administrator serwera CAS musi zarejestrować każdą aplikację kliencką (jej adres service URL) jako zaufaną usługę. Bez tego serwer CAS nie wyda biletów dla danej aplikacji.
  4. Implementacja filtra/interceptora: W aplikacji klienckiej deweloper konfiguruje filtr lub interceptor (część używanej biblioteki klienckiej), który przechwytuje żądania do chronionych zasobów.
    • Jeśli użytkownik nie ma aktywnej sesji w aplikacji, filtr przekierowuje do serwera CAS (krok 2 w perspektywie użytkownika).
    • Po powrocie z serwera CAS z Service Ticketem, filtr przechwytuje ten bilet.
  5. Walidacja Service Ticket: Biblioteka kliencka automatycznie wysyła Service Ticket do serwera CAS w celu walidacji. To jest krytyczny moment, w którym aplikacja kliencka dowiaduje się od zaufanego serwera CAS, kim jest zalogowany użytkownik.
  6. Tworzenie sesji lokalnej: Po otrzymaniu potwierdzenia od serwera CAS, aplikacja kliencka tworzy własną, lokalną sesję dla użytkownika i udziela mu dostępu. Od tego momentu aplikacja pracuje z danymi użytkownika, które otrzymała od CAS.

Dla dewelopera oznacza to mniej kodu do pisania i utrzymywania w zakresie uwierzytelniania, większe bezpieczeństwo i spójne doświadczenie dla użytkownika w całym ekosystemie aplikacji.

Zalety i Wyzwania w Implementacji `CAS logowanie`

Wprowadzenie systemu CAS logowanie do infrastruktury IT firmy to decyzja, która wiąże się z szeregiem korzyści, ale także z pewnymi wyzwaniami. Świadomość obu tych aspektów jest kluczowa dla skutecznej implementacji i długoterminowego sukcesu.

Zalety Systemu CAS:

  1. Single Sign-On (SSO) – Zwiększona wygoda użytkownika:

    Największą i najbardziej oczywistą zaletą jest możliwość logowania się raz i uzyskiwania dostępu do wielu aplikacji. To znacząco poprawia komfort pracy, eliminuje frustrację związaną z wielokrotnym wprowadzaniem danych i oszczędza czas. Użytkownicy cenią sobie płynne przechodzenie między systemami.

  2. Centralizacja Uwierzytelniania i Zarządzania Tożsamością:

    CAS przenosi odpowiedzialność za uwierzytelnianie z pojedynczych aplikacji na jeden, dedykowany serwer. Ułatwia to zarządzanie kontami użytkowników, wdrażanie spójnych polityk haseł i monitorowanie dostępu w całym środowisku. Zamiast zarządzać uwierzytelnianiem w każdej aplikacji z osobna, administratorzy konfigurują je tylko raz na serwerze CAS.

  3. Zwiększone Bezpieczeństwo:

    Scentralizowane uwierzytelnianie pozwala na implementację silniejszych mechanizmów bezpieczeństwa w jednym miejscu. Obejmuje to integrację z systemami takimi jak LDAP czy Active Directory, wsparcie dla uwierzytelniania dwuskładnikowego (MFA), a także łatwiejsze reagowanie na incydenty bezpieczeństwa. Aplikacje klienckie nie przechowują wrażliwych danych logowania, co zmniejsza ich powierzchnię ataku.

  4. Redukcja Obciążenia Deweloperskiego:

    Programiści nie muszą martwić się o implementację złożonych mechanizmów uwierzytelniania w każdej aplikacji. Mogą skupić się na funkcjonalności biznesowej, korzystając z gotowych bibliotek klienckich CAS, które obsługują komunikację z serwerem CAS.

  5. Elastyczność i Rozszerzalność:

    CAS jest protokołem otwartym i elastycznym. Serwer CAS można skonfigurować do współpracy z różnymi źródłami danych uwierzytelniających (bazy danych, LDAP, Active Directory, RADIUS, X.509) oraz do obsługi niestandardowych atrybutów użytkowników. Istnieje wiele modułów i wtyczek, które rozszerzają jego funkcjonalność.

  6. Otwarty Standard i Aktywna Społeczność:

    Jako projekt open source, CAS ma aktywną społeczność, która wspiera rozwój, dostarcza dokumentację i pomaga w rozwiązywaniu problemów. To zapewnia długoterminowe wsparcie i ciągłe doskonalenie systemu.

Wyzwania w Implementacji `CAS logowanie`:

  1. Złożoność Początkowej Konfiguracji:

    Chociaż CAS upraszcza życie na dłuższą metę, jego początkowa konfiguracja może być skomplikowana. Wymaga to dogłębnego zrozumienia protokołu, konfiguracji serwera CAS, źródeł uwierzytelniania oraz integracji z każdą aplikacją kliencką. Często trzeba dostosowywać szablony stron logowania, co wymaga umiejętności programistycznych.

  2. Pojedynczy Punkt Awarii (Single Point of Failure – SPoF):

    Serwer CAS jest centralnym punktem uwierzytelniania. Jeśli ulegnie awarii, żadna aplikacja zależna od CAS nie będzie mogła uwierzytelnić użytkowników. Wymaga to zaprojektowania architektury o wysokiej dostępności (HA), z redundancją, balansowaniem obciążenia i mechanizmami przełączania awaryjnego, co zwiększa koszty i złożoność infrastruktury.

  3. Wymagania dotyczące Zasobów:

    Serwer CAS, zwłaszcza w dużych środowiskach z tysiącami użytkowników i setkami aplikacji, może wymagać znacznych zasobów sprzętowych i oprogramowania (serwer JVM, baza danych, system operacyjny). Należy odpowiednio zaplanować skalowalność.

  4. Integracja z Aplikacjami Legacy:

    Integracja z bardzo starymi lub niestandardowymi aplikacjami, które nie mają wsparcia dla bibliotek klienckich CAS lub nie są zgodne z przekierowaniami HTTP, może być trudna lub niemożliwa. Czasami wymaga to napisania własnych adapterów.

  5. Utrzymanie i Aktualizacje:

    Jak każdy system, serwer CAS wymaga regularnych aktualizacji, łatek bezpieczeństwa i konserwacji. To wiąże się z koniecznością posiadania ekspertów, którzy potrafią zarządzać systemem i reagować na ewentualne problemy.

  6. Zależność od Protokołu HTTP/S:

    CAS jest protokołem opartym na przekierowaniach HTTP/S. Wymaga to odpowiedniej konfiguracji sieci, firewalla i certyfikatów SSL/TLS, aby zapewnić bezpieczną komunikację między wszystkimi komponentami. Błędy w konfiguracji certyfikatów lub przekierowań są częstą przyczyną problemów z uwierzytelnianiem CAS.

Podsumowując, choć CAS logowanie oferuje znaczące korzyści w zakresie wygody i bezpieczeństwa, jego wdrożenie wymaga starannego planowania, zasobów technicznych i uwzględnienia potencjalnych wyzwań operacyjnych.

Bezpieczeństwo w `CAS logowanie` – Kluczowe Aspekty

Bezpieczeństwo jest fundamentem każdego systemu uwierzytelniania, a w przypadku scentralizowanego rozwiązania takiego jak CAS logowanie, jego znaczenie jest jeszcze większe. Serwer CAS jest bramą do wielu aplikacji, dlatego jego ochrona jest absolutnie priorytetowa. Poniżej przedstawiamy kluczowe aspekty bezpieczeństwa, które należy wziąć pod uwagę.

1. Szyfrowana Komunikacja (HTTPS/SSL/TLS)

Jest to absolutna podstawa. Cała komunikacja między przeglądarką użytkownika a serwerem CAS, a także między aplikacjami klienckimi a serwerem CAS (podczas walidacji biletów), musi odbywać się przez bezpieczny kanał HTTPS. Użycie SSL/TLS zapobiega podsłuchiwaniu (sniffing) danych logowania, Service Ticketów i innych wrażliwych informacji przesyłanych w sieci. Należy regularnie dbać o aktualność certyfikatów SSL oraz o stosowanie najnowszych i najsilniejszych protokołów TLS.

2. Ochrona Biletów (TGT i ST)

  • Ticket Granting Ticket (TGT): TGT, przechowywany w ciasteczkach przeglądarki, jest kluczem do sesji SSO. Musi być zabezpieczony jako cookie `HttpOnly` (uniemożliwiające dostęp przez skrypty JavaScript) i `Secure` (wysyłane tylko przez HTTPS). Powinien mieć ograniczony czas życia (sesja lub krótki okres).
  • Service Ticket (ST): ST to jednorazowy token. Jego walidacja musi nastąpić natychmiast po otrzymaniu przez aplikację kliencką. Po walidacji ST staje się nieważny i nie może być ponownie użyty. To zapobiega atakom typu replay.

3. Walidacja Usług (Service Validation)

Serwer CAS musi dokładnie weryfikować, czy adres URL usługi (parametr service) podany przez aplikację kliencką jest zgodny z listą zaufanych, zarejestrowanych usług. Domyślnie CAS często pozwala na rejestrację usług poprzez wyrażenia regularne, co wymaga ostrożności. Należy unikać zbyt szerokich wzorców, które mogłyby pozwolić złośliwym domenom podszyć się pod zaufane aplikacje i przechwycić Service Tickety. Każda usługa powinna być ściśle zdefiniowana.

4. Uwierzytelnianie Dwuskładnikowe (Multi-Factor Authentication – MFA)

Integracja z MFA znacząco podnosi bezpieczeństwo systemu CAS. Po wprowadzeniu hasła, użytkownik musi podać drugi czynnik uwierzytelniający (np. kod z aplikacji mobilnej, token sprzętowy, odcisk palca). Ponieważ CAS jest scentralizowany, implementacja MFA w jednym miejscu zabezpiecza wszystkie podłączone aplikacje. Wiele implementacji CAS oferuje gotowe integracje z popularnymi dostawcami MFA.

5. Zabezpieczenia Przed Powszechnymi Atakami Webowymi

  • Cross-Site Scripting (XSS): Serwer CAS i strony logowania muszą być odporne na XSS, odpowiednio filtrując i kodując wszelkie dane wprowadzane przez użytkownika i odbierane z parametrów URL.
  • Cross-Site Request Forgery (CSRF): Chociaż CAS z natury jest mniej podatny na CSRF w procesie logowania (ze względu na przekierowania), należy upewnić się, że formularze logowania i inne operacje administracyjne na serwerze CAS są chronione przed takimi atakami.
  • SQL Injection / LDAP Injection: Jeśli CAS korzysta z baz danych lub serwerów LDAP do uwierzytelniania, należy bezwzględnie stosować bezpieczne metody dostępu do danych (np. parametryzowane zapytania, odpowiednie escape’owanie danych wejściowych) w celu zapobiegania atakom injecton.
  • Brute-Force i Słownikowe Ataki: Serwer CAS powinien implementować mechanizmy blokowania kont lub opóźniania odpowiedzi po wielu nieudanych próbach logowania, aby chronić przed atakami brute-force i słownikowymi.

6. Audyt i Logowanie

Serwer CAS powinien prowadzić szczegółowe logi wszystkich prób logowania (udanych i nieudanych), walidacji biletów i innych istotnych zdarzeń. Logi te są nieocenione w przypadku analizy incydentów bezpieczeństwa, wykrywania nietypowych zachowań i spełniania wymogów zgodności. Ważne jest, aby logi były przechowywane bezpiecznie i dostępne dla uprawnionych administratorów.

7. Regularne Audyty Bezpieczeństwa i Testy Penetracyjne

Okresowe audyty kodu, konfiguracji oraz testy penetracyjne serwera CAS i związanych z nim aplikacji są niezbędne. Pomagają one identyfikować i eliminować potencjalne luki w zabezpieczeniach, zanim zostaną wykorzystane przez atakujących.

Odpowiednia implementacja i ciągłe monitorowanie tych aspektów gwarantują, że CAS logowanie będzie bezpiecznym i niezawodnym filarem systemu uwierzytelniania w organizacji.

`CAS logowanie` a Inne Standardy Uwierzytelniania (SAML, OAuth2, OpenID Connect)

W świecie zarządzania tożsamością i dostępem (Identity and Access Management, IAM) istnieje wiele protokołów i standardów, które służą do uwierzytelniania i autoryzacji. CAS logowanie to jedno z nich, ale ważne jest, aby zrozumieć jego pozycję w szerszym krajobrazie i różnice w stosunku do innych popularnych rozwiązań, takich jak SAML, OAuth2 i OpenID Connect. Wybór odpowiedniego standardu zależy od konkretnych potrzeb, kontekstu i wymagań technicznych.

CAS (Central Authentication Service)

  • Czym jest: Otwarty protokół i implementacja do Single Sign-On (SSO) dla aplikacji webowych.
  • Główne zastosowanie: Pierwotnie zaprojektowany dla środowisk akademickich i dużych przedsiębiorstw do zapewnienia prostego, scentralizowanego uwierzytelniania dla wewnętrznych aplikacji webowych.
  • Model: Oparty na biletach (TGT, ST), opiera się na przekierowaniach HTTP.
  • Zalety: Prostota wdrożenia dla typowych scenariuszy webowych, łatwość integracji ze starszymi aplikacjami, elastyczność w podłączaniu źródeł danych uwierzytelniających (LDAP, AD itp.). Bardzo dojrzały i stabilny.
  • Ograniczenia: Głównie dla aplikacji webowych, mniej elastyczny w scenariuszach mobilnych czy API. Skupia się na uwierzytelnianiu, a nie na autoryzacji zasobów.

SAML (Security Assertion Markup Language)

  • Czym jest: Oparty na XML-u otwarty standard wymiany danych uwierzytelniających i autoryzacyjnych między domenami, służący do wdrożenia SSO.
  • Główne zastosowanie: Często wykorzystywany w scenariuszach enterprise-to-enterprise (federacyjne SSO) oraz w dostępie do aplikacji SaaS.
  • Model: Opiera się na wymianie „asetów” (assertions) między dostawcą tożsamości (Identity Provider, IdP) a dostawcą usług (Service Provider, SP).
  • Zalety: Bardzo wszechstronny, obsługuje złożone scenariusze, w tym SSO między różnymi organizacjami. Standardowy w wielu korporacyjnych środowiskach. Obsługuje zarówno uwierzytelnianie, jak i autoryzację.
  • Ograniczenia: Bardziej złożony w konfiguracji i implementacji niż CAS ze względu na swoją elastyczność i szczegółowość XML. Może być trudniejszy w debugowaniu.

OAuth2 (Open Authorization 2.0)

  • Czym jest: Ramowy standard autoryzacji, a nie protokół uwierzytelniania. Pozwala jednej aplikacji (klientowi) uzyskać ograniczony dostęp do zasobów użytkownika przechowywanych przez inną usługę (serwer zasobów), w imieniu użytkownika.
  • Główne zastosowanie: Umożliwia aplikacjom (np. mobilnym) dostęp do danych użytkownika na innych platformach (np. „Zaloguj się z Google, by uzyskać dostęp do zdjęć”).
  • Model: Użytkownik udziela zgody aplikacji klienckiej, która otrzymuje token dostępu (access token) od serwera autoryzacji. Token ten jest następnie używany do wywoływania API na serwerze zasobów.
  • Zalety: Stworzony z myślą o nowoczesnych aplikacjach, w tym mobilnych i API. Koncentracja na delegowaniu autoryzacji, a nie na uwierzytelnianiu. Bardzo elastyczny.
  • Ograniczenia: Sam w sobie nie zapewnia tożsamości użytkownika. Aplikacja kliencka nie wie, kim jest użytkownik, tylko czy ma dostęp do jego zasobów. Do uwierzytelniania często używa