Uwierzytelnianie a autoryzacja: na czym polega różnica?

by
Dawid Winiarski
Last update:
July 17, 2026

Czym jest ten przewodnik

Uwierzytelnianie i autoryzacja to dwa najczęściej mylone pojęcia w security, częściowo dlatego, że oba zaczynają się od „auth", a częściowo dlatego, że podczas logowania dzieje się to w odstępie kilku sekund. To nie jest to samo, a różnica ma znaczenie: większość luk w dostępie bierze się z tego, że jedno zostało dopięte dobrze, a drugie źle.

Ten przewodnik jest dla każdego, kto potrzebuje jasnego modelu myślowego: osób wchodzących do IT lub security, deweloperów spinających logowanie oraz menedżerów, którzy czytają te słowa w raportach z audytu i chcą, żeby przestały się im mylić. Definiuje oba pojęcia prostym językiem, używa codziennych analogii, pokazuje, gdzie każde z nich dzieje się podczas logowania, łączy je z kontrolami, które już znasz (MFA po jednej stronie, role i least privilege po drugiej), i wyjaśnia, dlaczego mylenie ich prowadzi do realnej ekspozycji.

  • Uwierzytelnianie odpowiada na pytanie „kim jesteś i czy potrafisz to udowodnić". NIST definiuje je jako „weryfikację tożsamości użytkownika, procesu lub urządzenia, zwykle jako warunek wstępny przyznania dostępu do zasobów w systemie informacyjnym" (NIST SP 800-53 Rev. 5, na podstawie FIPS 200).
  • Autoryzacja odpowiada na pytanie „co wolno ci zrobić, skoro już jesteś w środku". NIST definiuje ją jako „uprawnienia dostępu przyznane użytkownikowi, programowi lub procesowi, albo sam akt przyznawania tych uprawnień" (NIST SP 800-53 Rev. 5, na podstawie CNSSI 4009-2015).
  • Kolejność jest stała: uwierzytelnianie niemal zawsze zachodzi jako pierwsze, autoryzacja jako druga. Najpierw dowodzisz, kim jesteś, potem system decyduje, do czego ta tożsamość może sięgnąć.
  • Uwierzytelnianie wieloskładnikowe (MFA) wzmacnia uwierzytelnianie. Role, uprawnienia i least privilege rządzą autoryzacją. Silne MFA w żaden sposób nie ogranicza tego, co konto może zrobić, gdy już się zaloguje.
  • Mylenie tych dwóch pojęć daje przewidywalne luki: dobrze uwierzytelnione konto z dużo za dużym dostępem albo ścisłe uprawnienia siedzące za słabym logowaniem podatnym na phishing. Oba przypadki są częste, a każdy zostawia dziurę, którą miała pokryć ta druga kontrola.
  • Przydatny test dla dowolnej kontroli lub ustalenia z audytu: czy chodzi o potwierdzenie tożsamości (uwierzytelnianie), czy o decydowanie i ograniczanie tego, co tożsamość może zrobić (autoryzacja)? Niemal każda kontrola dostępu wpada wyraźnie do jednego z tych dwóch koszyków.

Czym jest uwierzytelnianie

Uwierzytelnianie to akt udowodnienia, że jesteś tym, za kogo się podajesz. System ma zapisaną tożsamość. Ty przedstawiasz dowód, że jesteś osobą, do której ta tożsamość należy, a system sprawdza, czy ten dowód się broni.

Standardowa definicja NIST brzmi: „weryfikacja tożsamości użytkownika, procesu lub urządzenia, zwykle jako warunek wstępny przyznania dostępu do zasobów w systemie informacyjnym". Dowód zwykle pochodzi z jednej lub więcej z trzech kategorii, często nazywanych czynnikami:

  • Coś, co wiesz, na przykład hasło lub PIN.
  • Coś, co masz, na przykład telefon, klucz bezpieczeństwa albo generator jednorazowych kodów.
  • Coś, czym jesteś, na przykład odcisk palca lub skan twarzy.

Samo hasło to uwierzytelnianie jednoskładnikowe. Wymóg drugiej kategorii, na przykład kodu z telefonu obok hasła, to uwierzytelnianie wieloskładnikowe. Cel uwierzytelniania jest wąski: ustalić, z rozsądną pewnością, że osoba przy klawiaturze jest prawowitym właścicielem konta. Nie mówi nic o tym, co to konto powinno móc robić.

Codzienna analogia. Uwierzytelnianie to bramkarz sprawdzający twój dowód przy wejściu. Jego zadaniem jest potwierdzić, że imię i nazwisko oraz twarz pasują do osoby, która je przedstawia. Bramkarz nie decyduje, do których pomieszczeń wejdziesz, gdy już będziesz w środku. To osobna decyzja, podejmowana przez kogoś innego, na podstawie czegoś innego niż twoja tożsamość.

Czym jest autoryzacja

Autoryzacja to akt decydowania, co wolno robić uwierzytelnionej tożsamości, a następnie egzekwowania tej decyzji. System już wie, kim jesteś. Teraz sprawdza swoje zasady: do jakich systemów, plików i działań ta tożsamość ma dostęp, a do jakich nie.

NIST definiuje autoryzację jako „uprawnienia dostępu przyznane użytkownikowi, programowi lub procesowi, albo sam akt przyznawania tych uprawnień". W praktyce autoryzacja przejawia się jako uprawnienia przypisane do twojego konta: foldery, które możesz otworzyć, rekordy, które możesz edytować, ustawienia, które możesz zmienić, działania administracyjne, które możesz wykonać. Dwie osoby mogą uwierzytelnić się jednakowo dobrze i mieć zupełnie inną autoryzację. Nowo zatrudniona osoba i dyrektor finansowy jednakowo dowodzą swojej tożsamości przy logowaniu, ale to, do czego mają potem dostęp, wcale nie jest takie samo.

Autoryzacja jest ściśle powiązana z kontrolą dostępu, którą NIST opisuje jako „proces przyznawania lub odmawiania konkretnych żądań uzyskania i wykorzystania informacji oraz powiązanych usług przetwarzania informacji". Autoryzacja to decyzja polityki, kto może co robić. Kontrola dostępu to szerszy mechanizm, który tę decyzję egzekwuje.

Codzienna analogia. Autoryzacja to system kart dostępu wewnątrz budynku. Bramkarza masz już za sobą, budynek już potwierdził, kim jesteś. Teraz każde drzwi sprawdzają, czy twoja karta ma prawo je otworzyć. Karta ogólnego dostępu otwiera lobby i twoje własne biuro. Karta działu technicznego otwiera serwerownię. Ta sama osoba, ta sama zweryfikowana tożsamość, inne drzwi.

Gdzie każde z nich zachodzi podczas logowania

Te dwa kroki najłatwiej rozdzielić, obserwując je po kolei podczas zwykłego logowania.

  1. Podajesz identyfikator. Wpisujesz nazwę użytkownika lub e-mail. To deklaracja, jeszcze nie dowód. Zgłaszasz, której tożsamości chcesz użyć.
  2. Zachodzi uwierzytelnianie. Wpisujesz hasło, a jeśli MFA jest włączone, dopełniasz drugi czynnik. System sprawdza dowód wobec tego, co ma zapisane. Jeśli się zgadza, twoja tożsamość zostaje potwierdzona i zostaje ustanowiona sesja. Jeśli nie, zatrzymujesz się tutaj i nigdy nie docierasz do kolejnego kroku.
  3. Zachodzi autoryzacja. Skoro system już wie, kim jesteś, stosuje swoje zasady. Gdy otwierasz konkretny raport, wchodzisz do panelu admina albo próbujesz usunąć rekord, system sprawdza, czy twoja tożsamość ma prawo do tego konkretnego działania. Niektóre sprawdzenia zachodzą raz, przy logowaniu, kiedy system ładuje twoje role, inne zachodzą bez przerwy, za każdym razem, gdy o coś nowego prosisz.

Uwierzytelnianie to głównie brama, przez którą przechodzisz raz, na początku. Autoryzacja to seria sprawdzeń, które zachodzą przez całą sesję, za każdym razem, gdy po coś sięgasz. Dlatego pojedyncze logowanie może się udać, a mimo to zablokować cię przed konkretnym folderem: uwierzytelniłeś się poprawnie, po prostu nie masz autoryzacji do tego zasobu.

Jak MFA, role i least privilege wpisują się w te dwa pojęcia

Kontrole, z którymi już masz do czynienia, wyraźnie dzielą się na jedną albo drugą kolumnę, a zobaczenie, do której kolumny należą, wyjaśnia, co każda z nich może, a czego nie może dla ciebie zrobić.

Po stronie uwierzytelniania:

  • Hasła i passkeys to sposób, w jaki tożsamość jest w ogóle dowodzona.
  • Uwierzytelnianie wieloskładnikowe (MFA) wzmacnia ten dowód, wymagając drugiego czynnika, więc samo skradzione hasło nie wystarczy.
  • Single sign-on (SSO) centralizuje uwierzytelnianie, więc jedno zaufane logowanie obsługuje wiele aplikacji, co daje jedno mocne miejsce do egzekwowania czynników i wykrywania podejrzanych logowań.

Wszystko w tej kolumnie dotyczy tego, żeby odpowiedź na pytanie „kim jesteś" trudniej było sfałszować. Nic z tego nie zmienia tego, co konto może zrobić, gdy już się zaloguje.

Po stronie autoryzacji:

  • Role grupują uprawnienia, więc dostęp można przypisywać według funkcji w pracy, a nie przełącznik po przełączniku. To podstawa kontroli dostępu opartej na rolach (RBAC).
  • Uprawnienia i nadania dostępu (entitlements) to pojedyncze nadania: przeczytaj to, edytuj tamto, zarządzaj jeszcze innym.
  • Least privilege to nadrzędna zasada, że każda tożsamość powinna mieć tylko taki dostęp, jakiego wymaga jej obecna rola w pracy, i nic ponadto.

Wszystko w tej kolumnie dotyczy decydowania i ograniczania tego, do czego potwierdzona tożsamość może sięgnąć. Nic z tego nie ma żadnego znaczenia dla tego, czy logowanie było prawdziwe.

Ten podział wyjaśnia coś, co wielu zaskakuje: MFA i least privilege rozwiązują różne problemy i się nie zastępują. MFA znacznie utrudnia atakującemu zalogowanie się jako ty, ale w żaden sposób nie ogranicza szkód, jeśli mu się to uda, bo po uwierzytelnieniu sesja ma dokładnie taki dostęp, jaki ma konto. Least privilege ogranicza te szkody, dbając o to, żeby konto od początku nie miało nadmiernego dostępu. Potrzebujesz obu, bo każde z nich zamyka lukę, którą to drugie zostawia otwartą.

Dlaczego mylenie tych dwóch pojęć prowadzi do luk w security

Gdy uwierzytelnianie i autoryzację traktuje się jako jedną rzecz, wynik jest prawie zawsze taki, że jedno z nich zostaje po cichu zaniedbane. Powtarzają się trzy wzorce.

Silne uwierzytelnianie, słaba autoryzacja. Zespół wdraża MFA wszędzie i uznaje dostęp za „załatwiony". Logowania są teraz trudne do sfałszowania, co jest realnym postępem. Ale konta stojące za tymi logowaniami wciąż noszą lata nagromadzonych uprawnień: analityk, który wciąż ma dostęp do systemów z poprzedniej roli, prawa admina przyznane na potrzeby jednorazowego projektu i nigdy nie odebrane, konto serwisowe o zakresie znacznie szerszym, niż faktycznie wykorzystuje. Drzwi wejściowe są wzmocnione, a drzwi wewnętrzne stoją otworem. Atakujący, któremu uda się przejść przez wejście, albo legalne konto użyte niezgodnie z przeznaczeniem, ma wtedy wolną rękę. MFA zweryfikowało, kto się zalogował, nigdy nie zapytało, czy ta tożsamość powinna mieć dostęp do aż tylu rzeczy.

Silna autoryzacja, słabe uwierzytelnianie. Sytuacja odwrotna. Uprawnienia są starannie dobrane, role są czyste, least privilege jest faktycznie stosowane, a cała ta konstrukcja stoi za hasłami bez drugiego czynnika. Wyłudzone albo powtórnie użyte hasło wprowadza atakującego prosto do środka jako legalnego użytkownika, a stamtąd starannie zaprojektowane zasady autoryzacji po prostu opisują, co atakujący może teraz zrobić. Ścisłe uprawnienia są tyle warte, ile wart jest dowód tożsamości, który ich strzeże.

Te dwa pojęcia mieszają się już na etapie projektowania. Gdy system „loguje cię" i od razu przyznaje szeroki dostęp bez osobnego kroku autoryzacji, weryfikacja tożsamości zaczyna pełnić też funkcję nadania uprawnień. Każdy, kto potrafi się uwierzytelnić, może zrobić niemal wszystko, a jedno przejęte konto staje się pełnym naruszeniem, bo nigdy nie było warstwy, która pytałaby, do czego ta zweryfikowana tożsamość faktycznie ma prawo.

Wspólny mianownik jest taki, że uwierzytelnianie i autoryzacja się uzupełniają, a nie zastępują. Każde z nich broni przed innym rodzajem awarii. Traktowanie jednego jako pokrycia dla drugiego zostawia lukę, którą miała wypełnić brakująca kontrola.

Uwaga o „authn" i „authz"

Można spotkać uwierzytelnianie skracane do authn i autoryzację do authz, zwłaszcza w rozmowach inżynierskich i narzędziach do zarządzania tożsamością. Ten skrót istnieje właśnie dlatego, że pełne słowa tak łatwo się myli w mowie i piśmie. Jeśli widzisz authn, czytaj „kim jesteś". Jeśli widzisz authz, czytaj „co wolno ci zrobić".

Tabela porównawcza

  • Na jakie pytanie odpowiada · Uwierzytelnianie (authn): Kim jesteś i czy potrafisz to udowodnić? · Autoryzacja (authz): Co wolno ci zrobić?
  • Ujęcie NIST · Uwierzytelnianie (authn): Weryfikacja tożsamości użytkownika, procesu lub urządzenia · Autoryzacja (authz): Uprawnienia dostępu przyznane użytkownikowi, procesowi lub tożsamości, albo sam akt ich przyznawania
  • Kiedy zachodzi · Uwierzytelnianie (authn): Najpierw, zwykle raz, przy logowaniu · Autoryzacja (authz): Po uwierzytelnieniu, często wielokrotnie w trakcie sesji
  • Co sprawdza · Uwierzytelnianie (authn): Dowód tożsamości: hasła, kody, klucze, biometrię · Autoryzacja (authz): Politykę i uprawnienia powiązane z tożsamością
  • Codzienna analogia · Uwierzytelnianie (authn): Bramkarz sprawdzający dowód przy wejściu · Autoryzacja (authz): Karta dostępu decydująca, które drzwi wewnętrzne się otworzą
  • Kluczowe kontrole · Uwierzytelnianie (authn): Hasła, passkeys, MFA, SSO · Autoryzacja (authz): Role, uprawnienia, least privilege, przeglądy dostępów
  • Tak wygląda awaria · Uwierzytelnianie (authn): Atakujący loguje się jako ktoś inny · Autoryzacja (authz): Konto sięga po rzeczy, do których nie powinno mieć dostępu
  • Czego nie robi · Uwierzytelnianie (authn): Nie decyduje, do czego masz dostęp · Autoryzacja (authz): Nie potwierdza, że logowanie jest prawdziwe

Źródła

  • NIST CSRC Glossary, authentication · https://csrc.nist.gov/glossary/term/authentication (definicja: weryfikacja tożsamości użytkownika, procesu lub urządzenia, zgodnie z FIPS 200 / NIST SP 800-53 Rev. 5)
  • NIST CSRC Glossary, authorization · https://csrc.nist.gov/glossary/term/authorization (definicja: uprawnienia dostępu przyznane użytkownikowi, programowi lub procesowi, albo sam akt przyznawania tych uprawnień, zgodnie z CNSSI 4009-2015 / NIST SP 800-53 Rev. 5)
  • NIST CSRC Glossary, access control · https://csrc.nist.gov/glossary/term/access_control (przyznawanie lub odmawianie konkretnych żądań uzyskania i wykorzystania informacji oraz powiązanych usług)
  • NIST SP 800-63-4, Digital Identity Guidelines · https://doi.org/10.6028/NIST.SP.800-63-4 (trzy czynniki uwierzytelniania: coś, co wiesz, co masz, i czym jesteś)
Subscribe to unshadowed.

Subscribe to receive the latest blog posts to your inbox and stay up to date with

By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

let's start with a conversation

Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.

Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.

We'll take it from there

Julian Machowski
Head of Technical Sales
+48 783 762 997
julian@unshadowit.com
Let's connect on LinkedIn
Message received. We'll be in touch soon.
Something failed. Try again or call us directly.