consdata.com
Blog techniczny Blog biznesowy Dział HR
EN
openid connect

O OpenID Connect słów kilka

author Michał Hoja
9 marca 2020

W nawiązaniu do mojego poprzedniego wpisu pt.:
“Keycloak - uwierzytelnianie i autoryzacja użytkownika w aplikacji Angular/Spring Boot” 🔗
chciałbym krótko opisać standard OpenID Connect, który został wykorzystany podczas logowania do aplikacji przy użyciu serwera uwierzytelniania Keycloak.

Wstęp

Najpopularniejszymi standardami wykorzystywanymi do uwierzytelniania/autoryzacji są OAuth 2.0, OpenID Connect oraz SAML.
O OAuth 2.0 zostało już napisanych wiele artykułów, których nie ma sensu powielać. Jednak aby przedstawić OpenID Connect, musiałbym opisać OAuth 2.0 oraz JWT.

W celu zapoznania się ze standardem OAuth 2.0 odeślę do artykułu pt.:
“OAuth 2.0 – jak działa / jak testować / problemy bezpieczeństwa” 🔗
autorstwa Marcina Pioska z portalu Sekurak, w którym została opisana terminologia, sposoby pozyskiwania tokenu oraz zasada działania standardu.

O JWT natomiast możemy przeczytać w dokumencie RFC7519.

Dlaczego więc do integracji naszej aplikacji z serwerem uwierzytelniania Keycloak użyliśmy OpenID Connect?

Uwierzytelnianie a autoryzacja

Poruszając temat zabezpieczania zasobów i dostępu do nich, mówimy o takich pojęciach jak uwierzytelnianie (ang. authentication) oraz autoryzacja (ang. authorization).

  • uwierzytelnianie to proces polegający na potwierdzeniu tożsamości, czyli w skrócie - kim jestem?;
  • autoryzacja to proces nadawania uprawnień (dostępu do zasobu), czyli w skrócie - co mogę zrobić?.

OAuth 2.0, według oficjalnej dokumentacji, nie powinien służyć do uwierzytelniania, a jedynie do autoryzacji (źródło 🔗):

OAuth 2.0 is not an authentication protocol.

Jeśli potrzebujemy mechanizmu pozwalającego na poprawne zaimplementowanie uwierzytelniania, z pomocą przychodzi OpenID Connect.

OpenID Connect

OpenID Connect jest prostą warstwą tożsamości opartą na OAuth 2.0.
Umożliwia klientom weryfikację tożsamości użytkownika końcowego na podstawie uwierzytelnienia przeprowadzonego przez serwer autoryzacji, a także uzyskanie podstawowych informacji o jego profilu. Rozszerza OAuth 2.0, umożliwiając uwierzytelnianie stowarzyszone (ang. federated authentication):

  • Federated Authentication - użytkownik loguje się do serwisu Spotify przy użyciu konta na portalu Facebook (OpenID Connect);
  • Delegated Authorization - Spotify próbuje uzyskać dostęp do listy znajomych na Facebooku, aby zaimportować ją do swojej bazy danych (OAuth 2.0).

Przepływ procesu jest podobny do OAuth 2.0, ale dodatkowo w procesie bierze udział ID Token.

ID Token

ID Token przypomina koncepcję dowodu osobistego w formacie JWT, podpisanego przez dostawcę OpenID (OP). Spełnia założenia standardu JWT, więc składa się z nagłówka, zawartości oraz sygnatury. Jego zawartość może więc wyglądać następująco:

{
  "jti": "e78b5f41-e769-4353-8874-44302f4a17c3",
  "exp": 1583205992,
  "nbf": 0,
  "iat": 1583169992,
  "iss": "http://localhost:8180/auth/realms/SpringBootAngular",
  "aud": "developer",
  "sub": "c3c3755a-e499-4782-b119-a19bede0ace8",
  "typ": "Serialized-ID",
  "nonce": "02c0b033-bfac-4030-a317-c18aec3cb2db",
  "auth_time": 1583169991,
  "acr" : "1",
  "session_state": "8b66127b-4474-41bd-8e36-5d18286df73f",
  "state_checker": "HZZmC4no-TEqiCf31Mk1MtONDqyxkk81ZXZCwANQb9Y",
  "name": "Jan Nowak",
  "email": "jan.nowak@example.pl"
}

W skrócie, ID Token m.in.:

  • potwierdza tożsamość użytkownika, zwanego podmiotem w OpenID (sub);
  • określa organ wydający (iss);
  • jest generowany dla określonej grupy odbiorców - klienta (aud);
  • może zawierać losowy ciąg służący do identyfikowania pochodzenia żądania (nonce);
  • może określać kiedy (auth time) i jak, pod względem siły (acr) użytkownik został uwierzytelniony;
  • posiada znacznik czasu wydania (iat) oraz czas ważności (exp);
  • może zawierać dodatkowe informacje takie jak imię, nazwisko (name) oraz adres email (email);
  • jest podpisany cyfrowo, dzięki czemu może zostać zweryfikowany;
  • opcjonalnie może zostać zaszyfrowany w celu zapewnienia poufności danych.

Więcej informacji na ten temat znajdziemy w oficjalnej dokumentacji 🔗.

Podsumowanie

Dzięki wykorzystaniu ID Token, OpenID Connect nadaje się do uwierzytelniania użytkownika, w przeciwieństwie do OAuth 2.0, który najlepiej sprawdzi się podczas autoryzacji dwóch aplikacji komunikujących się między sobą przez API.

Wiemy już, że Federated Authentication ma zastosowanie, kiedy użytkownik loguje się do serwisu przy użyciu wspólnego konta.
OpenID Connect wydaje się więc być naturalnym kandydatem do uwierzytelniania użytkowników w różnego rodzaju serwisach społecznościowych czy aplikacjach internetowych (jak w przykładzie logowania do aplikacji za pośrednictwem Keycloaka).

Delegated Authorization natomiast ma zastosowanie, kiedy klient (aplikacja) próbuje uzyskać dostęp do zasobów innej aplikacji. Użytkownik musi jedynie zaakceptować uprawnienia przyznawane aplikacji klienckiej, czyli np. odczyt listy znajomych na Facebooku, o który ubiega się Spotify.
Tutaj do autoryzacji Spotify w Facebooku najlepiej spisze się OAuth 2.0.

Standardy wymienione we wstępie można podsumować następująco:

  • OAuth 2.0 - stworzony w 2006 roku przy współpracy Twittera i Google, otwarty standard autoryzacji oparty o format JSON. Główne zastosowanie to autoryzacja API między dwoma aplikacjami;
  • OpenID Connect 1.0 - stworzony w 2014 roku przez OpenID Foundation, otwarty standard uwierzytelniania oparty o format JSON. Główne zastosowanie to SSO dla aplikacji konsumenckich;
  • SAML 2.0 - stworzony w 2001 roku przez OASIS, otwarty standard autoryzacji i uwierzytelniania oparty o format XML. Główne zastosowanie to SSO dla aplikacji enterprise.
Najnowsze wpisy

  • Dostępność w PDF - dokumenty bez barier
  • Czy wiesz, że z pomocą @starting-style można animować elementy z display: none za pomocą samego CSS?
  • Czy wiesz, że w Angular 17 została wprowadzona alternatywa dla *ngSwitch?
Dołącz do nas

  • SENIOR FULLSTACK DEVELOPER (JAVA + ANGULAR) Poznań (hybrydowo) lub zdalnie UoP 14 900 - 20 590 PLN brutto
    B2B 19 680 - 27 220 PLN netto
  • REGULAR FULLSTACK DEVELOPER (JAVA + ANGULAR) Poznań (hybrydowo) lub zdalnie UoP 11 300 - 15 900 PLN brutto
    B2B 14 950 - 21 000 PLN netto
  • ZOBACZ WSZYSTKIE OGŁOSZENIA

newsletter

techniczny

Zapisz się

Podobne wpisy

post-image
WCAG

Dostępność w PDF - dokumenty bez barier

author
Kacper Hoffman 28 kwi 2025
post-image
angular

Czy wiesz, że z pomocą @starting-style można animować elementy z display: none za pomocą samego CSS?

author
Piotr Tatarski 7 kwi 2025
post-image
angular

Czy wiesz, że w Angular 17 została wprowadzona alternatywa dla *ngSwitch?

author
Dorian Mejer 10 mar 2025
Dołącz do nas

  • SENIOR FULLSTACK DEVELOPER (JAVA + ANGULAR) Poznań (hybrydowo) lub zdalnie UoP 14 900 - 20 590 PLN brutto
    B2B 19 680 - 27 220 PLN netto
  • REGULAR FULLSTACK DEVELOPER (JAVA + ANGULAR) Poznań (hybrydowo) lub zdalnie UoP 11 300 - 15 900 PLN brutto
    B2B 14 950 - 21 000 PLN netto
  • ZOBACZ WSZYSTKIE OGŁOSZENIA

Zapisz się na

newsletter

techniczny

consdata.com
  • Kontakt

    • sales@consdata.com
    • +48 61 41 51 000

  • Biuro

    • K9Office
      Krysiewicza 9/14
      61-825 Poznań
      Polska

  • Rozwiązania

    • Eximee
    • Kouncil
  • Blog Dołącz do nas
Copyright © 2024 Consdata. All rights reserved. Privacy Policy & Cookies
Chcemy używać plików cookie oraz skryptów podmiotów trzecich do polepszania funkcjonowania tej strony Zgadzam się