Przewodnik po rejestracji aplikacji i OAuth do bezpiecznej integracji aplikacji

By Mirko Peters · 2026-05-04

Zarejestruj aplikację w protokole OAuth 2.0. Poznaj przepływ kodu autoryzacji, który zapewnia bezpieczny dostęp i jest kluczowym elementem przyznawania uprawnień kodem autoryzacji w OAuth 2.0.

Automatically translated with AI from the original post. Read the English original

Przyznajmy otwarcie: poprawna autentykacja i rejestracja aplikacji to nie tylko stosowanie sprytnych protokołów. Chodzi o to, by Twoi użytkownicy, Twoje dane i Twoja organizacja były bezpieczne. Ten przewodnik rozwiewa wątpliwości dotyczące rejestracji aplikacji i OAuth 2.0, tak abyś mógł budować bezpieczne, zgodne ze standardami uwierzytelnianie za pomocą Microsoft Entra ID (dawniej Azure AD) lub dowolnego wybranego przez siebie dostawcy.

Omówimy kroki i pojęcia, których potrzebujesz: od zrozumienia, dlaczego w ogóle stosuje się OAuth, po praktyczne wdrożenie w aplikacjach webowych, mobilnych lub SaaS. Po drodze znajdziesz jasne definicje, praktyczne wskazówki i plan działania, który pomoże utrzymać integrację na właściwym torze i uniknąć typowych potknięć, na które narażeni są programiści dopiero zaczynający pracę z OAuth. Niezależnie od tego, czy poznajesz ten temat po raz pierwszy, czy dopracowujesz zaawansowaną konfigurację w przedsiębiorstwie, trafiłeś we właściwe miejsce, aby budować z pewnością siebie i zrozumieć identyfikatory potrzebne Twojej aplikacji.

Przewodnik po rejestracji aplikacji i OAuth — definicja

Rejestracja aplikacji to proces tworzenia i konfigurowania tożsamości aplikacji u dostawcy tożsamości (takiego jak Azure AD, Google czy Auth0), dzięki czemu aplikacja może bezpiecznie żądać uwierzytelnienia i autoryzacji. Zazwyczaj obejmuje przypisanie identyfikatora klienta, sekretu klienta lub certyfikatu, zdefiniowanie identyfikatorów URI przekierowania, ustawienie uprawnień i zakresów oraz konfigurację dozwolonych typów przyznawania uprawnień.

8 zaskakujących faktów o przewodniku po rejestracji aplikacji i OAuth

• Sekrety klienta mogą wyciec przez logi: Wielu programistów podczas debugowania nieświadomie zapisuje w logach identyfikatory klientów i sekrety, przez co poświadczenia rejestracji aplikacji są narażone, dopóki zasady logowania nie zostaną zaostrzone. Identyfikatorami zawsze należy postępować ostrożnie.
• Identyfikatory URI przekierowania są surowsze, niż się spodziewasz: Dostawcy OAuth często wymagają dokładnej zgodności identyfikatorów URI przekierowania (łącznie z ukośnikami na końcu i schematem), więc drobne różnice mogą przerwać przepływy, które wydają się poprawnie skonfigurowane w rejestracji aplikacji.
• Klienci publiczni nie wymagają sekretów, ale nadal wymagają ochrony: Aplikacje natywne i jednostronicowe są traktowane jako klienci publiczni bez sekretów klienta, a mimo to muszą używać PKCE i bezpiecznych metod przekierowania, aby zapobiec przechwyceniu kodu.
• Zakresy domyślnie nie gwarantują zasady najmniejszych uprawnień: Podczas rejestrowania aplikacji domyślne zakresy lub ekrany zgody mogą żądać szerokich uprawnień. Aby wymusić zasadę najmniejszych uprawnień, niezbędne są jawne ograniczenia zakresów i przyrostowa zgoda.
• Unieważnianie tokenów nie jest powszechnie obsługiwane: Nie wszyscy dostawcy tożsamości respektują unieważnianie tokenów lub zapewniają natychmiastowe wylogowanie we wszystkich sesjach, dlatego rejestracja aplikacji musi obejmować zarządzanie sesjami i zasady tokenów odświeżania.
• Metadane rejestracji aplikacji są powierzchnią ataku: Publicznie widoczne nazwy aplikacji, logo i identyfikatory URI przekierowania mogą ułatwić atakującym przygotowanie wiarygodnego phishingu lub ataków z otwartym przekierowaniem, jeśli nie są starannie zarządzane.
• Zautomatyzowane udostępnianie może błędnie skonfigurować uprawnienia: Automatyzacja CI/CD tworzącą rejestracje aplikacji często przyznaje zbyt szerokie uprawnienia API lub nie rejestruje wymaganych identyfikatorów URI przekierowania, co prowadzi do cichych awarii albo ekspozycji na zagrożenia bezpieczeństwa.
• Interfejs zgody wpływa na decyzje dotyczące bezpieczeństwa: Użytkownicy i administratorzy często udzielają szerokiej zgody, ponieważ okna zgody są mylące. Projektowanie jasnych, minimalnych monitów o zgodę w rejestracji aplikacji i przewodniku po OAuth ogranicza nadmierne przyznawanie dostępu.

Zrozumienie OAuth 2.0 i podstaw Entra ID

OAuth 2.0 jest fundamentem nowoczesnych przepływów uwierzytelniania. Pozwala aplikacjom bezpiecznie uzyskiwać dostęp do danych i zasobów użytkownika, bez konieczności poznawania jego hasła. Poniżej przedstawiam zarys tego procesu. U podstaw OAuth 2.0 określa, jak ze sobą współpracują użytkownik („właściciel zasobu”), aplikacja („klient”) i dostawca tożsamości („serwer autoryzacji”), tak aby użytkownicy zachowali kontrolę nad swoimi informacjami.

Co jednak, gdy chcesz uwierzytelniać użytkowników, a nie tylko autoryzować dostęp do danych? Tutaj do głosu dochodzi OpenID Connect, który dodaje bezpieczną tożsamość i logowanie do OAuth 2.0. Dzięki OpenID Connect dostawcy tacy jak Microsoft Entra ID i Google pozwalają aplikacjom sprawdzić, kim są użytkownicy, oraz zażądać ograniczonych uprawnień do dodatkowych zasobów, a wszystko to w jednym, spójnym doświadczeniu.

Jeśli słyszysz takie pojęcia jak „client ID”, „authorization endpoint” czy „access token”, nie zniechęcaj się. Wszystkie sprowadzają się do określenia, kto z kim rozmawia i co może robić. Microsoft Entra ID wykorzystuje te protokoły, aby dać deweloperom oparty na standardach fundament, od aplikacji biznesowych działających w jednej dzierżawie po ogromne, wielodzierżawowe produkty SaaS.

Zrozumienie tych podstaw oznacza, że budujesz na sprawdzonym gruncie. Wybór właściwego przepływu OAuth dla danego scenariusza, na przykład code flow dla aplikacji webowych lub device flow dla smart TV, zapewnia bezpieczne i proste logowanie, któremu użytkownicy mogą ufać, a które docenia także zespół ds. zgodności.

Przewodnik po rejestracji aplikacji i OAuth: najczęstsze błędy w OAuth 2.0 i Entra ID

Ten przewodnik po rejestracji aplikacji i OAuth wymienia częste błędy, jakie zespoły popełniają podczas wdrażania OAuth 2.0 w Microsoft Entra ID (Azure AD), i opisuje, jak wpływają one na bezpieczeństwo, działanie aplikacji i doświadczenie użytkownika.

• Mieszanie pojęć OAuth 2.0 z OpenID Connect (np. oczekiwanie tokenów ID tam, gdzie wystawiane są wyłącznie tokeny dostępu).
• Niewłaściwe stosowanie przepływów OAuth, na przykład traktowanie przepływu niejawnego (implicit flow) jako odpowiedniego dla nowoczesnych aplikacji zamiast Authorization Code z PKCE.

• Nieprawidłowe rejestrowanie identyfikatorów URI przekierowania (zły schemat, końcowy ukośnik lub użycie localhost w środowisku produkcyjnym).
• Stosowanie ustawień klienta publicznego w aplikacjach poufnych lub odwrotnie, co prowadzi do błędów tokenów albo ujawnienia sekretów.
• Brak ustawienia odpowiednich uprawnień API i zakresów albo zapomnienie o udzieleniu zgody administratora tam, gdzie jest ona wymagana.

• Umieszczanie sekretów klienta w kodzie po stronie klienta lub w publicznych repozytoriach.
• Brak regularnej rotacji sekretów i certyfikatów oraz niewłaściwe usuwanie wygasłych poświadczeń z rejestracji aplikacji.
• Niepotrzebne używanie długotrwałych sekretów zamiast krótkotrwałych certyfikatów lub tożsamości zarządzanych.

• Brak prawidłowej walidacji tokenów (wystawca, odbiorca, podpis, nonce, exp).
• Niebezpieczne przechowywanie tokenów dostępu lub odświeżania, na przykład w local storage przeglądarki bez dodatkowych zabezpieczeń.
• Ufanie zawartości tokenów bez weryfikacji zakresów i ról zwróconych przez Entra ID.

• Założenie, że zgoda użytkownika oznacza uprawnienia aplikacji, bez świadomości, że niektóre uprawnienia wymagają zgody administratora.
• Żądanie nadmiernych uprawnień i zakresów, co prowadzi do zbędnego ryzyka oraz wyższego odsetka odrzuconych zgód.

• Brak obsługi rotacji i unieważniania tokenów odświeżania zgodnie z zasadami Entra ID, co skutkuje nieoczekiwanymi wylogowaniami.
• Używanie tokenów odświeżania w klientach publicznych bez odpowiedniej ochrony (zastosuj PKCE i odpowiednie czasy życia tokenów).

• Niepoprawna konfiguracja ustawień wielodzierżawowych w aplikacjach, które mają działać w wielu dzierżawach.
• Używanie niewłaściwych punktów końcowych (przypisanych do konkretnej dzierżawy zamiast common) i napotykanie problemów z logowaniem lub zgodą.

• Brak testowania zachowania aplikacji w sytuacji, gdy egzekwowane są dostęp warunkowy, MFA lub zasady zgodności urządzeń.
• Zakładanie, że tokeny zawsze będą wydawane w tych samych warunkach, to błąd — zasady mogą zablokować dostęp lub wymagać dodatkowych kroków uwierzytelniania.

• Stosowanie starszych przepływów OAuth lub wzorców Azure AD v1 zamiast zaleceń platformy tożsamości Microsoft (v2).
• Używanie przykładów społecznościowych bez sprawdzenia, czy implementują bezpieczne praktyki (PKCE, bezpieczne przechowywanie, prawidłowa walidacja).

• Brak rejestrowania błędów uwierzytelniania lub błędów wydawania tokenów, co utrudnia diagnozowanie problemów.
• Wyświetlanie użytkownikom surowych komunikatów o błędach zamiast czytelnych wskazówek, co zrobić dalej.

Skorzystaj z tego przewodnika po rejestracji aplikacji i OAuth, aby przejrzeć swoje wdrożenie, zastosować najlepsze praktyki platformy tożsamości Microsoft i ograniczyć ryzyko związane z bezpieczeństwem oraz eksploatacją podczas integracji OAuth 2.0 z Entra ID.

Wymagania wstępne rejestracji aplikacji na potrzeby konfiguracji OAuth

Zanim przejdziesz do ekranów rejestracji i wklejysz nazwę aplikacji do portalu, sprawdź kilka niezbędnych elementów. Po pierwsze, potrzebujesz dostępu do centrum administracyjnego Microsoft Entra swojej organizacji lub odpowiedniej konsoli dostawcy tożsamości, którego używasz — tu nie ma skrótów. Bez odpowiednich uprawnień utkniesz, zanim w ogóle zaczniesz.

Następnie zdecyduj, jaki typ aplikacji budujesz i jakie identyfikatory będą potrzebne do jej działania. Czy to aplikacja internetowa, jednostronicowa aplikacja (SPA), aplikacja mobilna, a może zautomatyzowana usługa? Każdy typ ma własne wymagania dotyczące uwierzytelniania i autoryzacji. Ten wybór z góry determinuje ustawienia zabezpieczeń, które wybierzesz później.

Warto też określić, kto będzie korzystał z aplikacji. Czy będą z niej korzystać wyłącznie osoby z Twojej organizacji (dzierżawa pojedyncza)? A może aplikacja ma obsługiwać użytkowników z innych firm lub szerszej publiczności (dzierżawa wielodostępowa)? Wpływa to na ustawienia rejestracji, na to, jakie katalogi użytkowników mają zastosowanie, oraz na przepływ zgody, który zobaczą użytkownicy.

Na koniec zbierz szczegóły techniczne, takie jak dozwolone adresy URL przekierowań po zalogowaniu, obsługiwane platformy (iOS, Android, Windows?) oraz uprawnienia (lub „zakresy”), o które aplikacja ma prosić. Uporządkowanie tych szczegółów oszczędza sporo czasu podczas konfiguracji i pozwala uniknąć typowych problemów, jak nieprawidłowe identyfikatory URI lub niezgodne typy kont w dalszym etapie.

Jak zarejestrować aplikację w Microsoft Entra ID

Rejestracja aplikacji w Microsoft Entra ID (dawniej Azure AD) wyznacza punkt wyjścia dla wszystkiego, co dotyczy uwierzytelniania i dostępu do interfejsów API. Proces zaczyna się w centrum administracyjnym Entra, gdzie utworzysz nową rejestrację aplikacji — nadając aplikacji unikalną tożsamość (zwaną „identyfikatorem klienta”) w katalogu Twojej organizacji.

Wpisz nazwę aplikacji, a następnie wybierz, kto może z niej korzystać: tylko Twoja organizacja, wiele organizacji czy dowolne konto Microsoft. Ten krok jest kluczowy — szczególnie w przypadku aplikacji SaaS i B2B — ponieważ określa zasięg aplikacji i sposób zarządzania zgodą dzierżawy.

Po wybraniu grupy odbiorców skonfiguruj szczegóły platformy aplikacji. W przypadku aplikacji internetowych dodasz identyfikator URI przekierowania; w przypadku aplikacji mobilnych lub jednostronicowych ustawienia specyficzne dla platformy zapewnią płynne logowanie. Portal Entra przeprowadzi Cię przez dodawanie poświadczeń, takich jak wpisy tajne klienta lub certyfikaty, których aplikacja użyje do potwierdzenia swojej tożsamości.

Ukończenie rejestracji dostosowuje aplikację do standardów OAuth 2.0 i sprawia, że przepływ uwierzytelniania pozostaje bezpieczny i zgodny z wymogami. Niezależnie od tego, czy wybierasz dzierżawę pojedynczą, czy wielodostępową, zrozumienie tych ustawień na wczesnym etapie tworzy solidne fundamenty pod przyszłą skalowalność i integracje.

Najważniejsze korzyści z rejestracji aplikacji w Microsoft Entra ID

• Scentralizowane zarządzanie tożsamością: zarządzaj uwierzytelnianiem, autoryzacją i tożsamościami użytkowników swojej aplikacji z poziomu jednej dzierżawy Entra ID.
• Bezpieczne przepływy OAuth: korzystaj z wbudowanej obsługi OAuth 2.0 i OpenID Connect, aby wdrażać bezpieczne logowanie, wydawanie tokenów i delegowany dostęp.
• Logowanie jednokrotne (SSO): zapewnij płynne logowanie jednokrotne w usługach Microsoft 365, Azure i innych zintegrowanych usługach, co poprawia komfort pracy użytkowników i ogranicza liczbę monitów o hasło.
• Szczegółowa kontrola uprawnień: definiowanie i zarządzanie szczegółowymi uprawnieniami interfejsu API, środowiskami wyrażania zgody oraz dostępem według zasady najmniejszych uprawnień, zarówno dla uprawnień delegowanych, jak i aplikacji.
• Dostęp warunkowy i zasady zabezpieczeń: wymuszanie uwierzytelniania wieloskładnikowego (MFA), zgodności urządzeń, lokalizacji oraz zasad opartych na ryzyku, aby chronić dostęp aplikacji i poufne dane.
• Zarządzane wpisy tajne i poświadczenia aplikacji: bezpieczne przechowywanie i rotacja wpisów tajnych klienta, certyfikatów oraz konfiguracji wielodzierżawnej wraz z praktykami zarządzania cyklem życia, aby zachować integralność użycia aplikacji.
• Integracja z usługami platformy Microsoft: dostęp do Microsoft Graph, interfejsów API platformy Azure, usługi Teams i innych możliwości platformy przy użyciu standardowych tokenów i modeli wyrażania zgody.
• Obsługa aplikacji hybrydowych i wieloplatformowych: uwierzytelnianie użytkowników w scenariuszach internetowych, mobilnych, desktopowych oraz usługa-usługa przy użyciu spójnych protokołów tożsamości, z dbaniem o to, aby każda aplikacja używała właściwych identyfikatorów.
• Monitorowanie i audyt: wykorzystanie dzienników, raportów logowania oraz informacji o zabezpieczeniach do wykrywania anomalii, badania incydentów i utrzymania zgodności.
• Skalowalność i gotowość do wdrożeń w przedsiębiorstwach: korzystanie z globalnej infrastruktury Entra ID, opcji wielodzierżawnych oraz funkcji przedsiębiorstwowych, aby obsługiwać rosnącą liczbę użytkowników i złożone potrzeby organizacji.
• Narzędzia deweloperskie i dokumentacja: Skorzystaj z zestawów SDK, przykładowego kodu oraz przewodnika po rejestracji aplikacji i protokole OAuth, aby przyspieszyć wdrożenie i rozwiązywać typowe scenariusze.

Konfigurowanie identyfikatorów URI przekierowania i ustawień platformy dla aplikacji Entra ID

Ustawienie prawidłowych identyfikatorów URI przekierowania podczas rejestracji aplikacji wydaje się proste, ale ten krok ma kluczowe znaczenie dla bezpieczeństwa. Identyfikatory URI przekierowania wskazują Entra ID, dokąd wysłać użytkowników (wraz z ich tokenami) po udanej próbie logowania. Podczas ich konfigurowania Entra wymusza ścisłe reguły: brak domen wieloznacznych, brak niebezpiecznych schematów URI i brak luk, które mogą wykorzystać atakujący.

Jeśli tworzysz aplikację jednostronicową (SPA), zazwyczaj użyjesz adresu URL HTTPS wskazującego na domenę aplikacji, aby zapewnić bezpieczną komunikację, dzięki której aplikacja pobiera dane. Natywne aplikacje wymagają schematów URI powiązanych z nazwą pakietu lub pakietu aplikacji, co uniemożliwia przypadkowym aplikacjom przejmowanie tokenów na tym samym urządzeniu. Aplikacje internetowe zwykle korzystają z punktów końcowych wywołania zwrotnego logowania — każdy z nich musi być jawnie wymieniony.

Błędna konfiguracja w tym zakresie prowadzi do klasycznych błędów „redirect URI mismatch” i, co gorsza, otwiera drzwi atakującym do przechwytywania tokenów. Poświęcenie czasu na zmapowanie każdej platformy, na której będzie działać aplikacja, wraz z odpowiadającymi jej identyfikatorami URI przekierowania, pomaga zapewnić sprawne uwierzytelnianie i spokój ducha.

Pamiętaj, aby aktualizować rejestrację aplikacji zawsze, gdy zmieniasz adresy URL klienta, dodajesz platformy lub rozszerzasz środowiska (np. testowe i produkcyjne). Utrzymanie tych identyfikatorów URI w zabezpieczeniu i uporządkowaniu to pierwszy krok do szczelnego przepływu tokenów.

Najważniejsze informacje o przepływach OAuth i zarządzaniu tokenami

OAuth 2.0 opiera się na zestawie przepływów autoryzacji, które obsługują różne przypadki użycia: logowania w aplikacjach internetowych, logowania w aplikacjach mobilnych, wywołania serwer-serwer lub aplikacje działające bez obecności użytkownika. Najpopularniejszym i najbezpieczniejszym z nich jest przepływ kodu autoryzacji, zaprojektowany tak, aby poufne tokeny nie trafiały do przeglądarek ani aplikacji mobilnych, a bezpieczeństwo było priorytetem.

Gdy użytkownik zostanie uwierzytelniony i udzieli zgody, aplikacja otrzymuje krótkotrwały kod. Musi wymienić go w punkcie końcowym tokenu na tokeny dostępu i odświeżania. Tokeny te przyznają czasowo ograniczony dostęp do danych — po ich wygaśnięciu token odświeżania może zażądać nowego tokenu dostępu, dzięki czemu sesja pozostaje aktywna.

Zarządzanie tokenami to nie tylko obsługa dat wygaśnięcia; chodzi o to, aby tokeny były bezpieczne na każdym etapie. Obejmuje to korzystanie z bezpiecznej komunikacji (np. HTTPS), nigdy nieujawnianie wpisów tajnych w kodzie po stronie klienta oraz stosowanie zasady najmniejszych uprawnień przy żądaniu zakresów.

Ta sekcja przygotowuje Cię do zrozumienia, jak OAuth obsługuje kluczowe uzgodnienia między użytkownikami, aplikacjami i platformami — oraz jak solidne zarządzanie tokenami wspiera trwałe, bezpieczne przepływy pracy zarówno dla użytkowników końcowych, jak i systemów automatycznych.

Implementacja przepływu kodu autoryzacji OAuth

1. Rozpocznij autoryzację: Twoja aplikacja przekierowuje użytkownika do punktu końcowego autoryzacji Entra ID, dołączając szczegóły, takie jak identyfikator klienta, żądane zakresy oraz unikatowy, losowy parametr state chroniący przed atakami CSRF.
2. Udzielenie uprawnień przez użytkownika: użytkownik przegląda ekran wyrażania zgody — w którym wyraźnie widać, jakich uprawnień potrzebuje aplikacja — i zatwierdza dostęp.
3. Otrzymanie kodu autoryzacyjnego: Po wyrażeniu zgody Entra ID przekierowuje z powrotem do określonego identyfikatora URI przekierowania, przekazując tymczasowy kod autoryzacyjny oraz wartość state, którą wcześniej ustawiono.
4. Wymiana kodu na tokeny: Zaplecze aplikacji bezpiecznie wysyła kod wraz z poświadczeniami klienta (a także weryfikatorem kodu PKCE, jeśli został użyty) do punktu końcowego tokenów Entra. Po pomyślnej weryfikacji otrzymujesz tokeny dostępu (a często także tokeny odświeżania).
5. Użycie tokenów do dostępu do interfejsów API: Aplikacja dołącza teraz token dostępu do każdego żądania API, potwierdzając autoryzację w imieniu użytkownika. Tokeny dostępu są ważne tylko przez krótki czas, co ogranicza ryzyko ich ujawnienia, a tokeny odświeżania służą do uzyskiwania nowych tokenów dostępu w trwających sesjach.

Prawidłowe wykonanie tych kroków we właściwej kolejności zamyka luki w zabezpieczeniach i pomaga zapobiegać atakom, takim jak przechwycenie kodu czy nadużycie tokenu, zwłaszcza gdy pracujesz z klientami publicznymi lub obsługujesz wrażliwe dane.

Najlepsze praktyki zarządzania wygasaniem tokenów dostępu i odświeżania

1. Bezpieczne przechowywanie tokenów: Korzystaj z bezpiecznych mechanizmów przechowywania dostarczanych przez system operacyjny, takich jak Keychain w systemie iOS, Keystore w systemie Android, lub zaszyfrowane menedżery sekretów po stronie serwera. Nigdy nie umieszczaj tokenów na stałe w plikach binarnych aplikacji ani nie zapisuj ich w dziennikach.
2. Uwzględnianie czasu życia tokenów: Monitoruj wartość wygaśnięcia (oświadczenie exp) w każdym tokenie i odświeżaj go z wyprzedzeniem, zanim wygaśnie, aby uniknąć nieudanych żądań API i złego doświadczenia użytkownika.
3. Obsługa rotacji tokenów: Zawsze używaj najnowszego tokenu odświeżania przy każdym żądaniu; szybko odrzucaj ponownie użyte lub nieaktualne tokeny. Ogranicza to skutki ewentualnego przejęcia tokenu.
4. Ograniczanie uprawnień w tokenach: Żądaj wyłącznie zakresów, których naprawdę potrzebujesz, i preferuj krótko żyjące tokeny dostępu. Znacząco zmniejsza to szkody, jeśli token kiedykolwiek wycieknie lub zostanie skradziony.

Zabezpieczanie implementacji OAuth w różnych kontekstach

Poprawna integracja OAuth to nie tylko odhaczanie kolejnych kroków, lecz budowanie warstw zabezpieczeń dopasowanych do architektury aplikacji i sposobu jej użycia. Niezależnie od tego, czy aplikacja działa w przeglądarce, na telefonie, czy wyłącznie w chmurze, potrzebujesz strategii uwierzytelniania dostosowanych do każdego z tych kontekstów.

Mechanizmy takie jak PKCE (Proof Key for Code Exchange) zabezpieczają przepływ kodu dla klientów publicznych, uniemożliwiając atakującym przechwycenie kodów i wymianę ich na tokeny. Z kolei w aplikacjach działających w bezpiecznym środowisku najlepszymi narzędziami do potwierdzania tożsamości i zarządzania zaufaniem są sekrety klienta i certyfikaty.

Przemyślane przechowywanie tokenów i czujne podejście do poziomów uprawnień pomagają unikać przypadkowych wycieków i ograniczają potencjalny zasięg szkód, gdyby coś poszło nie tak. Dobierając odpowiednie narzędzia bezpieczeństwa – PKCE, sekrety, certyfikaty i właściwe zakresy – znacząco zmniejszasz powierzchnię ataku i zwiększasz szanse na sprawne, zgodne z przepisami działanie.

Poniżej przedstawiamy sprawdzone strategie, które skutecznie przeciwdziałają typowym zagrożeniom i pomagają dostosować konfigurację OAuth tak, aby zapewniała solidną ochronę we wszystkich rodzajach aplikacji i środowisk.

Jak PKCE chroni autoryzację OAuth w klientach publicznych

PKCE (Proof Key for Code Exchange) ma kluczowe znaczenie przy używaniu OAuth w aplikacjach mobilnych i przeglądarkowych – w klientach publicznych, gdzie nie da się bezpiecznie przechowywać sekretu. Gdy rozpoczynasz przepływ kodu autoryzacyjnego, aplikacja generuje losowy „verifier kodu” oraz jego zhaszowaną wersję, czyli „code challenge”. Wartości te towarzyszą żądaniu użytkownika i końcowemu żądaniu tokenu. Nawet jeśli atakujący przechwyci kod autoryzacyjny, nie wymieni go na token bez tego tajnego weryfikatora, co sprawia, że ataki polegające na przechwytywaniu kodu są w usłudze Microsoft Entra ID i podobnych platformach niemal niemożliwe.

Zarządzanie sekretami klienta, certyfikatami i poświadczeniami federacyjnymi

• Sekrety klienta: Używane przez aplikacje poufne, takie jak zaufane usługi zaplecza, do potwierdzania swojej tożsamości w punkcie końcowym tokenów. Przechowuj sekrety w bezpiecznych magazynach, regularnie je rotuj i nigdy nie umieszczaj ich w kodzie aplikacji po stronie klienta.
• Certyfikaty: Aby zapewnić wyższy poziom pewności, zamiast zwykłych sekretów używaj certyfikatów X.509, które zwiększają bezpieczeństwo identyfikatorów aplikacji. Certyfikaty umożliwiają bezpieczniejszą weryfikację za pomocą par kluczy publiczny/prywatny i są idealne dla branż regulowanych lub aplikacji o rygorystycznych wymaganiach zgodności.
• Poświadczenia federacyjne: W konfiguracjach typu „przynieś własną tożsamość” używaj poświadczeń federacyjnych, takich jak tożsamość federacyjna Microsoft Entra lub zewnętrzni dostawcy. Umożliwia to uwierzytelnianie bez bezpośredniej obsługi sekretów, co zmniejsza obciążenie związane z zarządzaniem.
• Obsługa w potokach: W przepływach CI/CD wstrzykuj i rotuj sekrety oraz certyfikaty w miarę potrzeb, nigdy nie umieszczając ich na stałe w kontroli wersji. Automatyczne alerty o wygasaniu stanowią dodatkową warstwę odporności.

Zabezpieczanie tokenów i ograniczanie ekspozycji uprawnień

• Przechowuj tokeny wyłącznie w bezpiecznych lokalizacjach (magazyny systemu operacyjnego, zaszyfrowane środowiska serwerowe), nigdy w pamięci dostępnej dla użytkownika.
• Tokeny zawsze przesyłaj przez HTTPS lub bezpieczne kanały – zwykły protokół HTTP naraża tokeny na przechwycenie.
• Dla każdego tokenu żądaj minimalnych uprawnień („zakresów”) – nigdy nie proś o więcej, niż potrzebuje Twoja aplikacja.
• Regularnie audytuj wykorzystanie tokenów i przypisane uprawnienia, aby zapobiec niezauważonemu narastaniu zakresu uprawnień.

Najlepsze praktyki OAuth w aplikacjach mobilnych i natywnych

Aplikacje mobilne i natywne mają dziś specyficzne wyzwania: urządzenia się gubią, aplikacje współdzielą przestrzeń na dane, a użytkownicy oczekują szybkiego, niemal niewidocznego logowania. Dlatego stosowanie najlepszych praktyk OAuth na iOS, Androidzie i komputerach stacjonarnych – z wykorzystaniem wbudowanych zestawów SDK i sprawdzonych mechanizmów przechowywania danych – ma ogromne znaczenie.

Odpowiedni zestaw SDK (na przykład MSAL dla Microsoft Entra ID) przejmuje sporą część ciężkiej pracy: zarządza tokenami, obsługuje logikę odświeżania i integruje się z bezpiecznym magazynem systemu operacyjnego. W przypadku wrażliwych tokenów te zestawy SDK domyślnie wybierają najbezpieczniejsze miejsce przechowywania, uwzględniając specyfikę urządzeń i systemów operacyjnych.

Nie zapominaj o płynnym doświadczeniu użytkownika: uniwersalne linki, linki głębokie i przepływy w przeglądarce systemowej pomagają użytkownikom zakończyć logowanie bez zamieszania i bez ryzyka phishingu. Po prawidłowej konfiguracji aplikacja przekazuje użytkownika do bezpiecznego, zaufanego widoku internetowego systemu, a po zakończeniu logowania bezpiecznie przywraca go do wnętrza aplikacji – bez wyskakujących okien i bez wycieków tokenów.

Te praktyki mają na celu nie tylko ochronę tokenów, ale także budowanie zaufania użytkowników – zwiększają wskaźniki adopcji i zmniejszają w przyszłości obciążenie działu wsparcia.

Uniwersalne linki i natywne uwierzytelnianie pierwszej strony

Uniwersalne linki (w systemie iOS) oraz schematy aplikacji (w systemie Android) znacząco zwiększają bezpieczeństwo uwierzytelniania użytkowników. Dzięki linkom weryfikowanym przez system operacyjny, powiązanym z tożsamością Twojej aplikacji, nieuczciwe aplikacje nie przechwycą przekierowań logowania i nie wyłudzą tokenów, które do nich nie należą. Natywne uwierzytelnianie korzysta z zaufanych przeglądarek systemowych, dzięki czemu logowanie wykonuje rzeczywisty użytkownik – eliminuje to phishing, podsłuchiwanie tokenów i przypadkowe logowania w niepowiązanych aplikacjach. Razem te narzędzia zapewniają użytkownikom płynne i bezpieczne doświadczenie, które jest niemal odporne na typowe zagrożenia związane z OAuth w aplikacjach mobilnych.

Rozwiązywanie problemów z błędami OAuth i scenariusze zaawansowane

Integracje OAuth rzadko działają idealnie przy pierwszej próbie – błędy i nietypowe przypadki brzegowe są nieodłączną częścią pracy. Często problemy wynikają z niezgodności identyfikatorów URI przekierowania, wygasłych kodów lub błędnych sekretów klienta, które mogą całkowicie zablokować przepływy uwierzytelniania i wpłynąć na korzystanie z aplikacji. Ta sekcja pomoże Ci zinterpretować odpowiedzi z błędami, prześledzić nieudane wymiany i rozwiązać problemy, zanim trafią do Twojego działu helpdesk.

Poza podstawami niektóre scenariusze – takie jak komunikacja między aplikacjami serwer-serwer, logowanie urządzeń IoT czy potrzeba silniejszych gwarancji protokołu – wymagają wyspecjalizowanych rozszerzeń OAuth lub przepływów nieinteraktywnych. Konta usługowe, wzajemne TLS i przepływy kodu urządzenia zostały zaprojektowane właśnie z myślą o tych wymaganiach.

Dzięki wskazówkom dotyczącym zarówno typowych awarii, jak i zaawansowanych zastosowań będziesz lepiej przygotowany do diagnozowania, projektowania i utrzymywania niezawodnych rozwiązań OAuth, nawet gdy ekosystem Twoich aplikacji staje się coraz bardziej złożony.

Czy szukasz uporczywego błędu punktu końcowego tokenu, czy przygotowujesz aplikację na realia produkcyjne, gdzie wszędzie spotyka się urządzenia z ograniczonym wejściem i usługi bez interfejsu, te wskazówki pomogą utrzymać Twoje integracje w dobrej kondycji i bezpieczeństwie.

Dekodowanie odpowiedzi z błędami OAuth i niepowodzenia wymiany kodu

• Nieprawidłowy identyfikator URI przekierowania: występuje, gdy przekierowanie nie odpowiada zarejestrowanej liście; sprawdź dokładnie dane wejściowe, zwracając uwagę na wielkość liter.
• Wygasły kod autoryzacji: użytkownicy zwlekają zbyt długo lub kody są ponownie użyte; zawsze wykorzystuj je tylko raz i niezwłocznie po otrzymaniu.
• Niezgodne poświadczenia klienta: podano błędny sekret lub certyfikat; sprawdź poświadczenia i w razie potrzeby zmień je (rotuj).
• Nieprawidłowy zakres lub zasób: żądany interfejs API lub zakresy są niedozwolone albo źle wpisane; zweryfikuj konfigurację i uprawnienia aplikacji.

Konta usługowe, urządzenia z ograniczonym wejściem i rozszerzenia OAuth

• Konta usługowe (przepływ poświadczeń klienta): pozwalają aplikacjom uwierzytelniać się bez udziału użytkownika – idealne do automatyzacji i zadań serwer-serwer.
• Przepływ kodu urządzenia: przeznaczony dla telewizorów smart i urządzeń IoT; wyświetla użytkownikowi monit na innym urządzeniu – sprawdza się tam, gdzie przeglądarka nie jest dostępna.
• Rozszerzenie wzajemnego TLS: wykorzystuje certyfikaty zarówno po stronie serwera, jak i klienta, zwiększając bezpieczeństwo wrażliwych integracji i zapewniając, że aplikacja korzysta z silnych metod uwierzytelniania.
• Dynamiczna rejestracja klientów: automatyzuje wdrażanie aplikacji w dużych systemach SaaS lub wielodzierżawczych, upraszczając zarządzanie poświadczeniami na dużą skalę.

Przewodnik po rejestracji aplikacji i OAuth w Entra ID

Zalety

• Scentralizowane zarządzanie tożsamością: integracja z Microsoft Entra ID zapewnia spójną tożsamość użytkowników i aplikacji we wszystkich usługach.
• Rozbudowane mechanizmy bezpieczeństwa: obsługa OAuth 2.0, OpenID Connect, dostępu warunkowego oraz szczegółowych uprawnień (zakresów i ról).
• Standardowe protokoły branżowe: wykorzystanie powszechnie obsługiwanych standardów OAuth/OIDC ułatwia współpracę z narzędziami i bibliotekami innych dostawców.
• Szczegółowa konfiguracja aplikacji: możliwość ustawiania identyfikatorów URI przekierowania, certyfikatów i wpisów tajnych, uprawnień do interfejsów API oraz opcji brandingu aplikacji.
• Precyzyjny model zgód: obsługa uprawnień delegowanych i aplikacji wraz z przepływami zgody administratora, które ograniczają nadmierne uprawnienia aplikacji.
• Funkcje dla przedsiębiorstw: obsługa aplikacji wielodzierżawczych, współpracy B2B oraz integracji z usługami Microsoft 365 i Azure.
• Monitorowanie i audyt: wbudowane dzienniki, logi logowania i ślady audytu dla rejestracji aplikacji oraz przepływów OAuth, które ułatwiają zgodność z przepisami i rozwiązywanie problemów.
• Narzędzia dla deweloperów i zestawy SDK: rozbudowane zestawy SDK platformy tożsamości Microsoft, dokumentacja i przykłady szybkiego startu usprawniają wdrażanie.

Wady

• Złożoność dla początkujących: konfiguracja i modele uprawnień (identyfikatory URI przekierowania, adresy URL odpowiedzi, przepływy niejawne a z kodem autoryzacji, zakresy) mogą być mylące dla nowych deweloperów.
• Stroma krzywa uczenia się w zakresie funkcji bezpieczeństwa: dostęp warunkowy, tożsamości zarządzane i zaawansowane ustawienia tokenów wymagają głębszej wiedzy o bezpieczeństwie, aby skonfigurować je prawidłowo.
• Ryzyko rozrostu uprawnień: nieprawidłowe zgody lub szerokie uprawnienia aplikacji mogą prowadzić do nadmiernych uprawnień, jeśli nie są regularnie weryfikowane.
• Niuanse zarządzania tokenami: obsługa tokenów odświeżania, czasu ważności tokenów i ich unieważniania zachowuje się różnie w zależności od platformy, co może powodować problemy z integracją.
• Kwestie granic dzierżawy: zachowanie aplikacji wielodzierżawczych i monity o zgodę administratora zwiększają złożoność operacyjną w scenariuszach międzydzierżawczych.
• Zmiany interfejsu i nazewnictwa: Microsoft okresowo aktualizuje interfejs i nazwy Entra (Azure AD → Entra ID), co może prowadzić do rozbieżności w dokumentacji lub zamieszania.
• Zależność od ekosystemu Microsoft: silne powiązanie z funkcjami Entra ID może ograniczać przenośność do dostawców tożsamości spoza Microsoftu bez konieczności przeprojektowania.
• Możliwość błędnej konfiguracji: nieprawidłowe ustawienia rejestracji aplikacji (np. identyfikatory URI przekierowania, adresy URL odpowiedzi, ustawienia przepływu niejawnego) mogą tworzyć luki bezpieczeństwa lub przerywać przepływy uwierzytelniania.

Kolejne kroki i kluczowe zasoby społeczności dla sukcesu z OAuth

Dobrze, masz już skonfigurowany i działający OAuth, ale nie zwalniaj jeszcze tempa; upewnij się, że aplikacja pobierająca tokeny jest poprawnie skonfigurowana. Podstawowe połączenie to dopiero pierwszy krok. Jeśli naprawdę chcesz, by Twoja aplikacja się wyróżniała i chroniła użytkowników, czas zająć się dodatkami. Zacznij od zaawansowanych bibliotek klienckich, poeksperymentuj z Microsoft Graph i przyjrzyj się nowym funkcjom tożsamości, które mogą wzmocnić integrację i uczynić ją wygodniejszą dla wszystkich zaangażowanych.

Nie musisz też rozwiązywać tego sam. Dokumentacja Microsoft Entra ID jest równie obszerna jak jezioro Michigan: pełna aktualnych przewodników, przykładów kodu i szczegółowych specyfikacji technicznych, które z pewnością będziesz chciał mieć pod ręką. Wyrób sobie nawyk sprawdzania aktualizacji, zwłaszcza że standardy OAuth i tożsamości w chmurze wciąż się zmieniają.

Zadowolony z rejestracji aplikacji? Świetnie. Teraz zobacz, jak inni w praktyce wykazują się kreatywnością. Zajrzyj na fora deweloperskie, oficjalne tablice dyskusyjne, a nawet do repozytoriów GitHub bibliotek uwierzytelniania. Jeśli trafisz na ścianę, bardzo możliwe, że ktoś już rozwiązał Twój dokładnie ten problem albo przynajmniej na tyle głośno na niego narzekał, że ktoś musiał odpowiedzieć.

Jeśli lubisz majstrować i uczyć się przez działanie, sprawdź dostępne bezpłatne wersje próbne, dzierżawy testowe i funkcje w publicznej wersji zapoznawczej. Pozwalają one bezpiecznie coś zepsuć i sprawdzić, co działa, zanim wdrożysz zmiany dla prawdziwych użytkowników. Nie zapominaj też, że OAuth i bezpieczeństwo to wspólny wysiłek, więc dziel się swoimi sukcesami i pytaniami. Dzięki temu cały ekosystem pozostaje rzetelny i się rozwija, a wszyscy lepiej rozumieją przepływ działania OAuth.

Lista kontrolna przewodnika po rejestracji aplikacji i OAuth – Entra ID

• Zaplanuj typ aplikacji i model dostępu – zdecyduj między jednodzierżawczym, wielodzierżawczym lub osobistymi kontami Microsoft oraz określ, czy aplikacja będzie typu SPA, aplikacją internetową, mobilną, demonem lub usługą.
• Zarejestruj aplikację w Entra ID: utwórz nową rejestrację aplikacji o jasnej nazwie i z obsługiwanymi typami kont.
• Skonfiguruj identyfikatory URI przekierowania: dodaj poprawne identyfikatory URI przekierowania i wywołania zwrotnego dla każdej platformy (https, niestandardowy schemat, localhost na potrzeby dewelopmentu).
• Ustaw platformy aplikacji: włącz opcje platform SPA, aplikacji internetowej, mobilnej i desktopowej oraz w razie potrzeby skonfiguruj przepływy niejawne i przepływy przyznawania uprawnień.
• Twórz i zarządzaj tajnymi kluczami klienta: wygeneruj klucze tajne dla poufnych klientów, zanotuj datę wygaśnięcia i przechowuj je w bezpiecznym miejscu (Key Vault).
• Używaj certyfikatów do uwierzytelniania: w przypadku poufnych klientów produkcyjnych prześlij certyfikaty z kluczem publicznym zamiast długotrwałych kluczy tajnych.
• Skonfiguruj uprawnienia do interfejsów API: dodaj zakresy i uprawnienia do Microsoft Graph lub własnych interfejsów API, których wymaga aplikacja.
• Udziel zgody administratora tam, gdzie jest wymagana: poproś o zgodę administratora na uprawnienia delegowane wymagające zgody obejmującej całą dzierżawę i zarejestruj jej udzielenie.
• Zdefiniuj i udostępnij własne zakresy (w przypadku interfejsu API): dodaj zakresy w sekcji „Uwidacznianie interfejsu API” i określ ich nazwy, opisy oraz nazwy wyświetlane w zgodzie administratora.
• Skonfiguruj role aplikacji (w razie potrzeby): zdefiniuj role aplikacji i delegowane role dla kontroli dostępu opartej na rolach, a następnie przypisz je użytkownikom, grupom lub aplikacjom klienckim.
• Skonfiguruj CORS dla SPA wywołujących interfejsy API: dodaj dozwolone źródła w interfejsie API lub skonfiguruj zasady CORS w bramie.
• Wybierz przepływ OAuth 2.0: w zależności od potrzeb wybierz kod autoryzacji (z PKCE dla klientów publicznych), poświadczenia klienta dla aplikacji działających w tle lub kod urządzenia.
• Wdróż PKCE dla klientów publicznych: wymagaj Proof Key for Code Exchange w SPA i aplikacjach natywnych, aby zapobiec przechwyceniu kodu.
• Poprawnie weryfikuj tokeny: sprawdź wystawcę, odbiorcę, podpis, datę wygaśnięcia i wymagane oświadczenia, korzystając z bibliotek tożsamości Microsoft lub logiki walidacji JWT.
• Używaj Microsoft Authentication Libraries (MSAL): preferuj MSAL do pozyskiwania tokenów, buforowania, odświeżania i bezpiecznej obsługi na różnych platformach.
• Skonfiguruj dostęp warunkowy i MFA (w razie potrzeby): zastosuj zasady do rejestracji aplikacji lub przepływów logowania użytkowników, aby wymusić kontrolę zabezpieczeń.
• Monitoruj logowania i dzienniki inspekcji: włącz rejestrowanie i przeglądaj zdarzenia logowania, zgody oraz operacje administracyjne w dziennikach Entra ID.
• Stosuj zasadę najmniejszych uprawnień: żądaj wyłącznie uprawnień niezbędnych do działania i preferuj stopniowe udzielanie zgody, aby ograniczyć ekspozycję.
• Regularnie rotuj klucze tajne i certyfikaty: wdroż automatyczną rotację oraz alerty dotyczące wygasających poświadczeń.
• Zabezpieczaj kod i przechowywanie po stronie klienta: nie przechowuj kluczy tajnych w aplikacjach klienckich, korzystaj z bezpiecznego magazynu i najlepszych praktyk dla danej platformy.
• Testuj logowanie i przepływy tokenów w środowiskach dev/staging: sprawdzaj przepływy uwierzytelniania, czas życia tokenów, logikę odświeżania, obsługę błędów oraz doświadczenie użytkownika związane ze zgodą.
• Przygotuj dokumentację dla użytkowników i administratorów: uwzględnij kroki udzielania zgody, wymagane uprawnienia oraz wskazówki dotyczące rozwiązywania problemów.
• Okresowo przeglądaj i aktualizuj rejestracje aplikacji: sprawdzaj uprawnienia, role, klucze tajne i rejestracje pod kątem nieaktualnych lub nieużywanych aplikacji.
• Zastosuj ochronę sieci i interfejsów API: rozważ API Management, WAF, ograniczanie liczby żądań oraz punkty końcowe usługi w celu ochrony zaplecza interfejsów API.

azure access token – wykorzystanie oauth auth

Czym jest przewodnik po rejestracji aplikacji i oauth oraz dlaczego jest ważny?

Przewodnik po rejestracji aplikacji i oauth wyjaśnia, jak zarejestrować aplikację kliencką u dostawcy tożsamości (na przykład w usłudze azure) i wdrożyć przepływy autoryzacji OAuth 2.0, aby aplikacja mogła bezpiecznie żądać dostępu do chronionych zasobów. Jest to kluczowe niezależnie od tego, czy tworzysz aplikacje internetowe, aplikacje jednostronicowe (SPA), aplikacje desktopowe czy backendy serwerów WWW, ponieważ aplikacja potrzebuje identyfikatora aplikacji (application ID lub app ID), identyfikatora klienta oraz klucza tajnego klienta (w przypadku poufnych klientów), aby uzyskać token dostępu i, gdy to właściwe, token identyfikatora.

Jak zarejestrować aplikację w usłudze azure i uzyskać identyfikator aplikacji (application ID oraz app ID)?

Aby zarejestrować aplikację w usłudze azure, przejdź do portalu Azure, utwórz nową rejestrację aplikacji, podaj nazwę i identyfikatory URI przekierowania, a następnie zanotuj identyfikator klienta (identyfikator aplikacji) widoczny w przeglądzie aplikacji. Jeśli Twoja aplikacja jest poufnym klientem (serwer WWW lub tradycyjna aplikacja internetowa), utwórz klucz tajny klienta, który będzie używany razem z identyfikatorem klienta. Zarejestrowana aplikacja służy do autoryzacji i żądania tokenów dostępu do usług Microsoft.

Którego przepływu autoryzacji OAuth 2.0 należy użyć dla aplikacji jednostronicowych (SPA)?

Aplikacje jednostronicowe (SPA) powinny używać przepływu kodu autoryzacji z PKCE (proof key for code exchange) zamiast przepływu niejawnego, dzięki czemu wymiana tokenów przez aplikację jest bezpieczna. Przepływ kodu z PKCE pozwala aplikacji bezpiecznie wymienić kod na token dostępu po stronie klienta działającego w przeglądarce, dzięki czemu aplikacje jednostronicowe mogą korzystać z protokołu OAuth bez ujawniania sekretów klienta w przeglądarce.

Jak działa żądanie autoryzacji i jakie parametry są wymagane?

Żądanie autoryzacji jest wysyłane do punktu końcowego autoryzacji dostawcy tożsamości i zazwyczaj zawiera client_id (identyfikator aplikacji), response_type (na przykład code), redirect_uri, scope oraz state. W przypadku aplikacji jednostronicowych korzystających z przepływu kodu z PKCE należy dodatkowo uwzględnić code_challenge i code_challenge_method. Użytkownik uwierzytelnia się i wyraża zgodę (zgoda OAuth), a serwer autoryzacji zwraca kod na adres redirect URI, który aplikacja może wymienić na token dostępu.

Jak zakodować wymianę kodu na token dostępu (code for an access token)?

Po otrzymaniu kodu autoryzacji aplikacja kliencka wysyła żądanie do punktu końcowego tokenów, zawierające kod, client_id (a w przypadku klientów poufnych także client_secret), redirect_uri oraz grant_type=authorization_code. W przypadku PKCE należy dołączyć code_verifier. Punkt końcowy tokenów zwraca token dostępu, token ID (jeśli został zażądany) oraz ewentualnie token odświeżania, który pozwala uzyskać nowy token dostępu po wygaśnięciu bieżącego.

Jak uzyskać token dostępu i używać go do wywoływania interfejsów API?

Token dostępu uzyskujesz, przechodząc wybrany przepływ autoryzacji OAuth 2.0 i wywołując punkt końcowy tokenów. Gdy masz już token dostępu, przesyłaj go w nagłówku Authorization jako Bearer podczas wywoływania usług Microsoft lub innych interfejsów API (na przykład Kalendarza Google albo własnych interfejsów API). Weryfikuj tokeny po stronie serwera internetowego lub zasobu, aby upewnić się, że żądania aplikacji są autoryzowane.

Co zrobić, gdy token dostępu wygaśnie, i jak uzyskać nowy token odświeżania?

Gdy token dostępu wygaśnie, użyj tokenu odświeżania (jeśli został wystawiony), aby zażądać nowego tokenu dostępu z punktu końcowego tokenów, z parametrem grant_type=refresh_token. Niektóre przepływy lub dostawcy wystawiają nowy token odświeżania przy odnawianiu, inni mogą ponownie wykorzystać ten sam. Jeśli token odświeżania nie jest dostępny (klienty publiczne lub krótkotrwałe przepływy), przekieruj użytkownika z powrotem do aplikacji, aby wykonać nowe żądanie autoryzacji.

Czy potrzebuję osobnych rejestracji aplikacji dla aplikacji internetowych i aplikacji mobilnych lub desktopowych?

Osobne rejestracje aplikacji są często potrzebne, gdy typy aplikacji znacząco się różnią (na przykład tradycyjna aplikacja serwerowa, aplikacje jednostronicowe i aplikacje desktopowe), ponieważ różnią się adresy redirect URI, sekrety klienta i dozwolone przepływy. Osobne rejestracje pozwalają skonfigurować konkretne przepływy autoryzacji i adresy redirect URI dla każdego typu aplikacji.

Jaka jest różnica między rejestracją aplikacji klienckiej a aplikacją w dzierżawie?

Rejestracja aplikacji klienckiej to konkretny wpis rejestracji u dostawcy tożsamości (aplikacja platformy Azure), który przechowuje konfigurację, taką jak adresy redirect URI i sekrety. Aplikacja w dzierżawie oznacza, że rejestracja znajduje się w określonej dzierżawie Azure AD i może mieć przypisane role oraz uprawnienia w tej dzierżawie. Pojedyncza rejestracja aplikacji może być wielodzierżawcza lub jednodzierżawcza, w zależności od potrzeb.

Jak zażądać dostępu do usług Microsoft i jakie uprawnienia są potrzebne?

Dostęp żąda się, określając zakresy (scopes), których potrzebuje aplikacja, w żądaniu autoryzacji. W przypadku usług Microsoft skonfiguruj uprawnienia API w rejestracji aplikacji platformy Azure, a następnie poproś użytkowników o wyrażenie zgody (zgoda OAuth) lub zleć administratorowi udzielenie zgody dla całej dzierżawy. Aplikacja żąda zakresów, takich jak User.Read, lub własnych zakresów interfejsu API w ramach żądań aplikacji, a następnie używa tokenu dostępu do wywoływania usług.

Jak zabezpieczyć sekrety klienta i uniknąć wycieku danych uwierzytelniających w aplikacjach jednostronicowych?

Aplikacje jednostronicowe nie powinny przechowywać sekretów klienta, ponieważ kod działający w przeglądarce może zostać sprawdzony. Użyj przepływu kodu autoryzacji z PKCE, aby aplikacja mogła bezpiecznie uzyskać token dostępu bez sekretu klienta. Dla aplikacji poufnych (serwerowych) przechowuj identyfikator klienta i sekret klienta po stronie serwera, gdzie nie są widoczne dla użytkowników.

Jaka jest rola adresu redirect URI i dlaczego musi być zgodny z rejestracją aplikacji?

Redirect URI (identyfikator URI przekierowania) to adres, na który dostawca tożsamości wysyła odpowiedź autoryzacji (kod lub token). Musi on być zgodny z URI przekierowania zarejestrowanym w rejestracji aplikacji, aby zapobiec przejęciu odpowiedzi autoryzacji. Użyj dokładnego dopasowania lub dozwolonych wzorców zdefiniowanych przez dostawcę; niezgodność spowoduje błąd wymiany tokenu.

Jak sprawić, aby użytkownicy się uwierzytelniali i otrzymywali token id oprócz tokenu dostępu?

Aby otrzymać token id, zażądaj zakresu openid oraz użyj parametru response_type, który uruchamia wystawienie tokenu ID (przepływ kodu autoryzacji z openid). Token id zawiera deklaracje tożsamości uwierzytelnionego użytkownika. Użyj tokenu id, aby zalogować użytkownika w swojej aplikacji klienckiej, a tokenu dostępu do wywoływania zależnych interfejsów API.

Jakie konkretne przepływy autoryzacji dotyczą tradycyjnych aplikacji internetowych, a jakie aplikacji jednostronicowych?

Tradycyjne aplikacje internetowe (po stronie serwera) zazwyczaj korzystają z przepływu kodu autoryzacji z poświadczeniami klienta (identyfikator klienta i klucz tajny klienta) i wymieniają kod na serwerze WWW. Aplikacje jednostronicowe (SPA) używają przyznania kodu autoryzacji z PKCE i bez klucza tajnego klienta. Aplikacje desktopowe również korzystają z PKCE. Wybór przepływu zależy od typu aplikacji oraz od tego, gdzie można bezpiecznie przechowywać sekrety.

Czy jedną rejestrację aplikacji można wykorzystać dla wielu aplikacji klienckich, czy też powinienem utworzyć osobną rejestrację dla każdej aplikacji?

Jedną rejestrację aplikacji można wykorzystać dla wielu aplikacji klienckich, jeśli mają one tę samą konfigurację i identyczne URI przekierowania. Najlepsze praktyki zazwyczaj zalecają jednak osobne rejestracje aplikacji dla odrębnych aplikacji, aby odizolować uprawnienia, URI przekierowania i zarządzanie cyklem życia. Rozważ, czy aplikacja może wymagać innych zakresów uprawnień lub innego zachowania zgody administratora.

Jak sprawdzać tokeny w swoim serwerze WWW lub interfejsie API?

Serwer WWW lub interfejs API powinien weryfikować podpis, wystawcę, odbiorcę (identyfikator aplikacji lub application id) oraz datę ważności tokenu dostępu lub tokenu id. Użyj dokumentu wykrywania dostawcy, aby uzyskać klucze podpisujące, i stosuj zalecane biblioteki walidacyjne dla swojej platformy. Walidacja gwarantuje, że akceptowane są tylko żądania od uwierzytelnionych i autoryzowanych aplikacji.

Jaki jest proces żądania tokenu dostępu dla usługi zaplecza przy użyciu poświadczeń klienta?

W scenariuszach serwer-serwer zarejestruj aplikację w usłudze Microsoft Entra ID, przyznaj jej uprawnienia aplikacji, a następnie użyj przepływu poświadczeń klienta: wyślij żądanie POST do punktu końcowego tokenu z parametrami grant_type=client_credentials, client_id, client_secret oraz scope lub resource. Punkt końcowy zwraca token dostępu, którego usługa zaplecza może użyć do wywoływania usług Microsoft lub chronionych interfejsów API.

Jak obsługiwać zgodę OAuth i zgodę administratora w aplikacjach wielodzierżawczych?

Gdy aplikacja jest zarejestrowana jako wielodzierżawcza, użytkownicy z innych dzierżaw mogą wyrazić zgodę na uprawnienia delegowane podczas żądania autoryzacji. W przypadku uprawnień wymagających zgody administratora, zgodę w swojej dzierżawie musi udzielić administrator. Aby administratorzy dzierżaw mogli masowo udzielać zgody OAuth, dołącz instrukcje oraz adres URL zgody.

Jakie kroki rozwiązywania problemów należy podjąć, gdy żądanie autoryzacji się nie powiedzie?

Sprawdź, czy aplikacja jest zarejestrowana w portalu Microsoft, czy URI przekierowania jest zgodny, czy identyfikator i klucz tajny klienta są poprawne, czy zakresy są prawidłowe oraz czy typ przyznania i parametry PKCE (jeśli są używane) są poprawne. Przeanalizuj komunikaty o błędach zwracane przez punkt końcowy autoryzacji lub tokenu oraz dzienniki po stronie klienta i serwera. Przy konkretnych kodach błędów pomocne mogą być Stack Overflow oraz dokumentacja dostawcy.

Jak zintegrować interfejsy API innych dostawców, takie jak Kalendarz Google, z moją zarejestrowaną aplikacją?

Aby zintegrować Kalendarz Google lub inne interfejsy API firm trzecich, wdróż przepływy autoryzacji OAuth 2.0 wymagane przez tych dostawców. Aplikacja musi żądać odpowiednich zakresów dla interfejsu API firmy trzeciej i obsługiwać osobne cykle życia tokenów. Może być konieczna osobna rejestracja aplikacji klienckiej u każdego dostawcy oraz koordynacja uzyskiwania tokenów dostępu dla każdej usługi.

Kiedy należy używać przepływu kodu urządzenia lub innych specjalnych przepływów dla określonych urządzeń?

Przepływu kodu urządzenia użyj w przypadku urządzeń o ograniczonych możliwościach wprowadzania danych, na których nie ma przeglądarki. Przepływ urządzenia pozwala użytkownikowi odwiedzić adres URL weryfikacji na innym urządzeniu i uwierzytelnić się tam. Jest to jeden ze specjalnych przepływów autoryzacji obsługiwanych obok przepływu kodu, poświadczeń klienta i odświeżania tokenów, dzięki czemu można dostosować się do różnych typów aplikacji i urządzeń.