Translated ['', 'src/pentesting-cloud/azure-security/az-basic-informatio

src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md

@@ -1,100 +1,100 @@
-# Az - Tokens & Public Applications
+# Az - Tokeny i publiczne aplikacje
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Podstawowe informacje
 
-Entra ID to platforma zarządzania tożsamością i dostępem (IAM) w chmurze firmy Microsoft, stanowiąca podstawowy system uwierzytelniania i autoryzacji dla usług takich jak Microsoft 365 i Azure Resource Manager. Azure AD wdraża ramy autoryzacji OAuth 2.0 oraz protokół uwierzytelniania OpenID Connect (OIDC) do zarządzania dostępem do zasobów.
+Entra ID to chmurowa platforma zarządzania tożsamością i dostępem (IAM) Microsoftu, służąca jako podstawowy system uwierzytelniania i autoryzacji dla usług takich jak Microsoft 365 i Azure Resource Manager. Azure AD implementuje framework autoryzacji OAuth 2.0 oraz protokół uwierzytelniania OpenID Connect (OIDC) do zarządzania dostępem do zasobów.
 
 ### OAuth
 
 **Kluczowi uczestnicy w OAuth 2.0:**
 
-1. **Serwer zasobów (RS):** Chroni zasoby należące do właściciela zasobów.
-2. **Właściciel zasobów (RO):** Zazwyczaj użytkownik końcowy, który posiada chronione zasoby.
-3. **Aplikacja kliencka (CA):** Aplikacja starająca się o dostęp do zasobów w imieniu właściciela zasobów.
-4. **Serwer autoryzacji (AS):** Wydaje tokeny dostępu aplikacjom klienckim po ich uwierzytelnieniu i autoryzacji.
+1. **Resource Server (RS):** Chroni zasoby należące do właściciela zasobów.
+2. **Resource Owner (RO):** Zazwyczaj końcowy użytkownik będący właścicielem chronionych zasobów.
+3. **Client Application (CA):** Aplikacja żądająca dostępu do zasobów w imieniu właściciela zasobów.
+4. **Authorization Server (AS):** Wydaje tokeny dostępu aplikacjom klienckim po ich uwierzytelnieniu i autoryzacji.
 
-**Zakresy i zgoda:**
+**Scopes i zgoda:**
 
-- **Zakresy:** Szczegółowe uprawnienia zdefiniowane na serwerze zasobów, które określają poziomy dostępu.
-- **Zgoda:** Proces, w którym właściciel zasobów przyznaje aplikacji klienckiej pozwolenie na dostęp do zasobów z określonymi zakresami.
+- **Scopes:** Szczegółowe uprawnienia zdefiniowane na serwerze zasobów, określające poziomy dostępu.
+- **Consent:** Proces, w którym właściciel zasobów przyznaje aplikacji klienckiej uprawnienia do dostępu do zasobów z określonymi scopes.
 
 **Integracja z Microsoft 365:**
 
-- Microsoft 365 wykorzystuje Azure AD do IAM i składa się z wielu aplikacji OAuth "pierwszej strony".
-- Aplikacje te są głęboko zintegrowane i często mają wzajemne relacje serwisowe.
-- Aby uprościć doświadczenia użytkowników i zachować funkcjonalność, Microsoft przyznaje "domyślną zgodę" lub "wstępną zgodę" tym aplikacjom pierwszej strony.
-- **Domyślna zgoda:** Niektóre aplikacje są automatycznie **przyznawane dostęp do określonych zakresów bez wyraźnej zgody użytkownika lub administratora**.
-- Te wstępnie wyrażone zgody są zazwyczaj ukryte zarówno przed użytkownikami, jak i administratorami, co sprawia, że są mniej widoczne w standardowych interfejsach zarządzania.
+- Microsoft 365 używa Azure AD do IAM i składa się z wielu "first-party" OAuth aplikacji.
+- Aplikacje te są głęboko zintegrowane i często mają współzależne relacje serwisowe.
+- Aby uprościć doświadczenie użytkownika i utrzymać funkcjonalność, Microsoft przyznaje tym first-party aplikacjom "implied consent" lub "pre-consent".
+- **Implied Consent:** Niektóre aplikacje są automatycznie **przyznawane dostęp do określonych scopes bez jawnej zgody użytkownika lub administratora**.
+- Te pre-consented scopes są zazwyczaj ukryte przed użytkownikami i administratorami, co sprawia, że są mniej widoczne w standardowych interfejsach zarządzania.
 
-**Typy aplikacji klienckich:**
+**Rodzaje aplikacji klienckich:**
 
-1. **Klienci poufni:**
+1. **Confidential Clients:**
 - Posiadają własne poświadczenia (np. hasła lub certyfikaty).
-- Mogą **bezpiecznie uwierzytelniać się** na serwerze autoryzacji.
-2. **Klienci publiczni:**
+- Mogą **bezpiecznie uwierzytelniać się** u authorization servera.
+2. **Public Clients:**
 - Nie mają unikalnych poświadczeń.
-- Nie mogą bezpiecznie uwierzytelniać się na serwerze autoryzacji.
-- **Implikacja bezpieczeństwa:** Atakujący może podszyć się pod publiczną aplikację kliencką podczas żądania tokenów, ponieważ nie ma mechanizmu, który pozwalałby serwerowi autoryzacji zweryfikować legalność aplikacji.
+- Nie mogą bezpiecznie uwierzytelniać się u authorization servera.
+- **Implikacja bezpieczeństwa:** Atakujący może podszyć się pod public client aplikację podczas żądania tokenów, ponieważ authorization server nie ma mechanizmu weryfikacji prawdziwości aplikacji.
 
 ## Tokeny uwierzytelniające
 
-Istnieją **trzy typy tokenów** używanych w OIDC:
+W OIDC używane są **trzy typy tokenów**:
 
-- [**Tokeny dostępu**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Klient przedstawia ten token serwerowi zasobów, aby **uzyskać dostęp do zasobów**. Może być używany tylko dla określonej kombinacji użytkownika, klienta i zasobu i **nie może być unieważniony** do momentu wygaśnięcia - co wynosi domyślnie 1 godzinę.
-- **Tokeny ID**: Klient otrzymuje ten **token od serwera autoryzacji**. Zawiera podstawowe informacje o użytkowniku. Jest **powiązany z określoną kombinacją użytkownika i klienta**.
-- **Tokeny odświeżające**: Przyznawane klientowi wraz z tokenem dostępu. Używane do **uzyskiwania nowych tokenów dostępu i ID**. Jest powiązany z określoną kombinacją użytkownika i klienta i może być unieważniony. Domyślne wygaśnięcie wynosi **90 dni** dla nieaktywnych tokenów odświeżających i **brak wygaśnięcia dla aktywnych tokenów** (z tokena odświeżającego można uzyskać nowe tokeny odświeżające).
-- Token odświeżający powinien być powiązany z **`aud`**, z pewnymi **zakresami** oraz z **dzierżawą** i powinien być w stanie generować tokeny dostępu tylko dla tego aud, zakresów (i nic więcej) oraz dzierżawy. Jednak nie jest to przypadek w przypadku **tokenów aplikacji FOCI**.
-- Token odświeżający jest szyfrowany i tylko Microsoft może go odszyfrować.
-- Uzyskanie nowego tokena odświeżającego nie unieważnia poprzedniego tokena odświeżającego.
+- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Klient przekazuje ten token serwerowi zasobów, aby **uzyskać dostęp do zasobów**. Może być użyty tylko dla konkretnej kombinacji użytkownika, klienta i zasobu i **nie może zostać unieważniony** aż do wygaśnięcia — domyślnie 1 godzina.
+- **ID Tokens**: Klient otrzymuje ten **token od serwera autoryzacji**. Zawiera podstawowe informacje o użytkowniku. Jest **powiązany z konkretną kombinacją użytkownika i klienta**.
+- **Refresh Tokens**: Dostarczane klientowi wraz z tokenem dostępu. Służą do **uzyskiwania nowych access i ID tokenów**. Są powiązane z konkretną kombinacją użytkownika i klienta i mogą być unieważnione. Domyślny okres wygaśnięcia to **90 dni** dla nieaktywnych refresh tokenów i **brak wygaśnięcia dla aktywnych tokenów** (z refresh tokena można otrzymać nowe refresh tokeny).
+- Refresh token powinien być powiązany z polem **`aud`**, z pewnymi **scopes** oraz z **tenantem** i powinien generować access tokeny tylko dla tego aud, tych scopes (i nie więcej) oraz tego tenant. Jednak nie dotyczy to tokenów aplikacji **FOCI**.
+- Refresh token jest zaszyfrowany i tylko Microsoft może go odszyfrować.
+- Uzyskanie nowego refresh tokena nie unieważnia poprzedniego refresh tokena.
 
 > [!WARNING]
-> Informacje o **dostępie warunkowym** są **przechowywane** wewnątrz **JWT**. Jeśli więc zażądają Państwo **tokena z dozwolonego adresu IP**, ten **IP** zostanie **przechowany** w tokenie, a następnie można użyć tego tokena z **niedozwolonego IP, aby uzyskać dostęp do zasobów**.
+> Informacje dotyczące **conditional access** są **przechowywane** wewnątrz **JWT**. Zatem, jeśli zażadasz **tokenu z dozwolonego adresu IP**, ten **adres IP** zostanie **zapisany** w tokenie i potem możesz użyć tego tokenu z **adresu IP, który nie jest dozwolony, aby uzyskać dostęp do zasobów**.
 
-### Tokeny dostępu "aud"
+### Access Tokens "aud"
 
-Pole wskazane w polu "aud" to **serwer zasobów** (aplikacja) używany do przeprowadzenia logowania.
+Pole wskazane w polu "aud" to **serwer zasobów** (aplikacja) używana do przeprowadzenia logowania.
 
-Polecenie `az account get-access-token --resource-type [...]` obsługuje następujące typy, a każdy z nich doda określone "aud" w wynikowym tokenie dostępu:
+Polecenie `az account get-access-token --resource-type [...]` obsługuje następujące typy, a każdy z nich doda specyficzne "aud" do otrzymanego access tokena:
 
 > [!CAUTION]
-> Zauważ, że poniższe to tylko API obsługiwane przez `az account get-access-token`, ale jest ich więcej.
+> Zauważ, że poniższe to tylko API obsługiwane przez `az account get-access-token`, ale istnieją też inne.
 
 <details>
 
-<summary>przykłady aud</summary>
+<summary>aud examples</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: Używane do uzyskiwania dostępu do przestarzałego API Azure AD Graph (deprecjonowane), które pozwala aplikacjom na odczyt i zapis danych katalogowych w Azure Active Directory (Azure AD).
+- **aad-graph (Azure Active Directory Graph API)**: Używane do uzyskania dostępu do przestarzałego Azure Active Directory Graph API (deprecated), które pozwala aplikacjom na odczyt i zapis danych katalogu w Azure Active Directory (Azure AD).
 - `https://graph.windows.net/`
 
-* **arm (Azure Resource Manager)**: Używane do zarządzania zasobami Azure za pośrednictwem API Azure Resource Manager. Obejmuje operacje takie jak tworzenie, aktualizowanie i usuwanie zasobów, takich jak maszyny wirtualne, konta magazynowe i inne.
+* **arm (Azure Resource Manager)**: Używane do zarządzania zasobami Azure przez Azure Resource Manager API. Obejmuje operacje takie jak tworzenie, aktualizacja i usuwanie zasobów takich jak maszyny wirtualne, konta storage i inne.
 - `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Używane do uzyskiwania dostępu do Azure Batch, usługi, która umożliwia efektywne uruchamianie aplikacji obliczeniowych w chmurze na dużą skalę.
+- **batch (Azure Batch Services)**: Używane do dostępu do Azure Batch, usługi umożliwiającej wydajne uruchamianie aplikacji równoległych i HPC w chmurze.
 - `https://batch.core.windows.net/`
 
-* **data-lake (Azure Data Lake Storage)**: Używane do interakcji z Azure Data Lake Storage Gen1, które jest skalowalną usługą przechowywania danych i analityki.
+* **data-lake (Azure Data Lake Storage)**: Używane do interakcji z Azure Data Lake Storage Gen1, skalowalną usługą przechowywania danych i analityki.
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Używane do uzyskiwania dostępu do Azure Media Services, które oferują usługi przetwarzania i dostarczania mediów w chmurze dla treści wideo i audio.
+- **media (Azure Media Services)**: Używane do dostępu do Azure Media Services, które oferują przetwarzanie i dostarczanie mediów (wideo i audio) w chmurze.
 - `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Używane do uzyskiwania dostępu do Microsoft Graph API, zjednoczonego punktu końcowego dla danych usług Microsoft 365. Umożliwia dostęp do danych i informacji z usług takich jak Azure AD, Office 365, Enterprise Mobility i usługi bezpieczeństwa.
+* **ms-graph (Microsoft Graph API)**: Używane do dostępu do Microsoft Graph API, zunifikowanego punktu końcowego dla danych usług Microsoft 365. Pozwala uzyskać dostęp do danych i informacji z usług takich jak Azure AD, Office 365, Enterprise Mobility i Security services.
 - `https://graph.microsoft.com`
 
-- **oss-rdbms (Azure Open Source Relational Databases)**: Używane do uzyskiwania dostępu do usług baz danych Azure dla otwartych silników baz danych, takich jak MySQL, PostgreSQL i MariaDB.
+- **oss-rdbms (Azure Open Source Relational Databases)**: Używane do dostępu do usług baz danych Azure dla open-source'owych silników relacyjnych, takich jak MySQL, PostgreSQL i MariaDB.
 - `https://ossrdbms-aad.database.windows.net`
 
 </details>
 
-### Zakresy tokenów dostępu "scp"
+### Access Tokens Scopes "scp"
 
-Zakres tokena dostępu jest przechowywany wewnątrz klucza scp w tokenie dostępu JWT. Te zakresy definiują, do czego token dostępu ma dostęp.
+Zakres access tokena jest przechowywany w kluczu scp wewnątrz access token JWT. Te scopes definiują, do czego access token ma dostęp.
 
-Jeśli JWT ma prawo kontaktować się z określonym API, ale **nie ma zakresu** do wykonania żądanej akcji, **nie będzie w stanie wykonać akcji** z tym JWT.
+Jeśli JWT ma uprawnienie do kontaktu z konkretnym API, ale **nie ma scope** pozwalającego wykonać żądaną akcję, **nie będzie w stanie wykonać tej akcji** przy użyciu tego JWT.
 
-### Przykład uzyskania tokena odświeżającego i dostępu
+### Przykład pobierania refresh i access tokenów
 ```python
 # Code example from https://github.com/secureworks/family-of-client-ids-research
 import msal
@@ -106,7 +106,7 @@ from typing import Any, Dict, List
 
 # LOGIN VIA CODE FLOW AUTHENTICATION
 azure_cli_client = msal.PublicClientApplication(
-"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
+"00b41c95-dab0-4487-9791-b9d2c32c80f2" # ID for Office 365 Management
 )
 device_flow = azure_cli_client.initiate_device_flow(
 scopes=["https://graph.microsoft.com/.default"]
@@ -146,29 +146,30 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
 ### Inne pola tokena dostępu
 
-- **appid**: Identyfikator aplikacji używany do generowania tokena
-- **appidacr**: Referencja klasy kontekstu uwierzytelniania aplikacji wskazuje, jak klient został uwierzytelniony, dla publicznego klienta wartość wynosi 0, a jeśli użyto tajnego klucza klienta, wartość wynosi 1
-- **acr**: Roszczenie referencji klasy kontekstu uwierzytelniania wynosi "0", gdy uwierzytelnienie użytkownika końcowego nie spełnia wymagań ISO/IEC 29115.
-- **amr**: Metoda uwierzytelniania wskazuje, jak token został uwierzytelniony. Wartość "pwd" wskazuje, że użyto hasła.
-- **groups**: Wskazuje grupy, w których główny użytkownik jest członkiem.
-- **iss**: Wydawca identyfikuje usługę tokenów bezpieczeństwa (STS), która wygenerowała token. np. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid to identyfikator dzierżawy)
-- **oid**: Identyfikator obiektu głównego użytkownika
-- **tid**: Identyfikator dzierżawy
-- **iat, nbf, exp**: Wydany (kiedy został wydany), Nie przed (nie może być używany przed tym czasem, zazwyczaj ta sama wartość co iat), Czas wygaśnięcia.
+- **appid**: Identyfikator aplikacji użyty do wygenerowania tokena
+- **appidacr**: Application Authentication Context Class Reference wskazuje, w jaki sposób klient został uwierzytelniony — dla publicznego klienta wartość to 0, a jeśli użyto sekretu klienta (client secret) wartość to 1
+- **acr**: Authentication Context Class Reference ma wartość "0", gdy uwierzytelnienie użytkownika końcowego nie spełnia wymagań ISO/IEC 29115.
+- **amr**: Metoda uwierzytelniania wskazuje, w jaki sposób token został uwierzytelniony. Wartość „pwd” oznacza, że użyto hasła.
+- **groups**: Wskazuje grupy, których członkiem jest podmiot.
+- **iss**: Issuer identyfikuje security token service (STS), który wygenerował token, np. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid to tenant ID)
+- **oid**: ID obiektu podmiotu
+- **tid**: ID dzierżawy (tenant ID)
+- **iat, nbf, exp**: Issued at (kiedy został wydany), Not before (nie można używać przed tym czasem, zwykle ta sama wartość co iat), Expiration time (czas wygaśnięcia).
+
 
 ## Eskalacja uprawnień tokenów FOCI
 
-Wcześniej wspomniano, że tokeny odświeżające powinny być powiązane z **zakresami**, z którymi zostały wygenerowane, z **aplikacją** i **dzierżawą**, do której zostały wygenerowane. Jeśli jakikolwiek z tych ograniczeń zostanie naruszony, możliwe jest eskalowanie uprawnień, ponieważ będzie można generować tokeny dostępu do innych zasobów i dzierżaw, do których użytkownik ma dostęp, oraz z większymi zakresami, niż pierwotnie zamierzano.
+Wcześniej wspomniano, że refresh tokens powinny być powiązane z **scopes**, z **application** i z **tenant**, dla których zostały wygenerowane. Jeśli któreś z tych ograniczeń zostanie złamane, możliwa jest eskalacja uprawnień — będzie można wygenerować access tokens do innych zasobów i tenantów, do których użytkownik ma dostęp, oraz z większymi scopes niż pierwotnie przewidziano.
 
-Co więcej, **jest to możliwe ze wszystkimi tokenami odświeżającymi** w [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (konto Microsoft Entra, konta osobiste Microsoft oraz konta społecznościowe, takie jak Facebook i Google), ponieważ jak wspominają [**dokumenty**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Tokeny odświeżające są powiązane z kombinacją użytkownika i klienta, ale **nie są powiązane z zasobem ani dzierżawą**. Klient może użyć tokena odświeżającego do uzyskania tokenów dostępu **w dowolnej kombinacji zasobów i dzierżaw**, gdzie ma na to pozwolenie. Tokeny odświeżające są szyfrowane i tylko platforma tożsamości Microsoft może je odczytać."
+Co więcej, **jest to możliwe dla wszystkich refresh tokens** w [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google), ponieważ, jak wspominają [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Refresh tokens are bound to a combination of user and client, but **aren't tied to a resource or tenant**. A client can use a refresh token to acquire access tokens **across any combination of resource and tenant** where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."
 
-Ponadto, należy zauważyć, że aplikacje FOCI są aplikacjami publicznymi, więc **nie jest potrzebny żaden sekret** do uwierzytelnienia na serwerze.
+Dodatkowo, aplikacje FOCI są aplikacjami publicznymi, więc **żaden sekret nie jest potrzebny** do uwierzytelnienia się na serwerze.
 
-Następnie znane klientów FOCI zgłoszone w [**oryginalnych badaniach**](https://github.com/secureworks/family-of-client-ids-research/tree/main) można [**znaleźć tutaj**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
+Znane klienty FOCI zgłoszone w [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) można [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
 
 ### Uzyskaj inny zakres
 
-Kontynuując poprzedni przykład kodu, w tym kodzie żądany jest nowy token dla innego zakresu:
+Kontynuując wcześniejszy przykład kodu, w tym fragmencie żądany jest nowy token dla innego zakresu:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -185,7 +186,7 @@ scopes=[
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-### Uzyskaj różne klienty i zakresy
+### Uzyskaj innego klienta i inne zakresy
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
@@ -201,27 +202,28 @@ scopes=["https://graph.microsoft.com/.default"],
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
-## Gdzie znaleźć tokeny
+## Gdzie znaleźć tokens
 
-Z perspektywy atakującego bardzo interesujące jest wiedzieć, gdzie można znaleźć tokeny dostępu i odświeżania, gdy na przykład komputer ofiary jest skompromitowany:
+Z perspektywy atakującego bardzo istotne jest wiedzieć, gdzie można znaleźć access i refresh tokens, np. gdy komputer ofiary zostanie skompromitowany:
 
-- W **`<HOME>/.Azure`**
-- **`azureProfile.json`** zawiera informacje o zalogowanych użytkownikach z przeszłości
-- **`clouds.config` zawiera** informacje o subskrypcjach
-- **`service_principal_entries.json`** zawiera dane uwierzytelniające aplikacji (id najemcy, klienci i sekret). Tylko w Linux i macOS
-- **`msal_token_cache.json`** zawiera tokeny dostępu i tokeny odświeżania. Tylko w Linux i macOS
-- **`service_principal_entries.bin`** i **`msal_token_cache.bin`** są używane w Windows i są szyfrowane za pomocą DPAPI
+- Inside **`<HOME>/.Azure`**
+- **`azureProfile.json`** zawiera informacje o wcześniej zalogowanych użytkownikach
+- **`clouds.config contains`** informacje o subskrypcjach
+- **`service_principal_entries.json`** zawiera poświadczenia aplikacji (tenant id, clients and secret). Tylko w Linux & macOS
+- **`msal_token_cache.json`** zawiera access tokens i refresh tokens. Tylko w Linux & macOS
+- **`service_principal_entries.bin`** and msal_token_cache.bin są używane w Windows i są zaszyfrowane za pomocą DPAPI
 - **`msal_http_cache.bin`** to pamięć podręczna żądań HTTP
-- Załaduj to: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
-- **`AzureRmContext.json`** zawiera informacje o wcześniejszych logowaniach za pomocą Az PowerShell (ale nie zawiera danych uwierzytelniających)
-- W **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** znajdują się różne pliki `.bin` z **tokenami dostępu**, tokenami ID i informacjami o koncie szyfrowanymi za pomocą DPAPI użytkownika.
-- Można znaleźć więcej **tokenów dostępu** w plikach `.tbres` wewnątrz **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`**, które zawierają tokeny dostępu szyfrowane w base64 za pomocą DPAPI.
-- W Linux i macOS można uzyskać **tokeny dostępu, tokeny odświeżania i tokeny ID** z Az PowerShell (jeśli używane) uruchamiając `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
-- W Windows to generuje tylko tokeny ID.
-- Możliwe jest sprawdzenie, czy Az PowerShell był używany w Linux i macOS, sprawdzając, czy istnieje `$HOME/.local/share/.IdentityService/` (chociaż zawarte pliki są puste i bezużyteczne)
-- Jeśli użytkownik jest **zalogowany w Azure w przeglądarce**, zgodnie z tym [**postem**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web), możliwe jest rozpoczęcie procesu uwierzytelniania z **przekierowaniem do localhost**, co sprawia, że przeglądarka automatycznie autoryzuje logowanie i otrzymuje token odświeżania. Należy zauważyć, że istnieje tylko kilka aplikacji FOCI, które pozwalają na przekierowanie do localhost (takich jak az cli lub moduł powershell), więc te aplikacje muszą być dozwolone.
+- Load it: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
+- **`AzureRmContext.json`** zawiera informacje o wcześniejszych logowaniach przy użyciu Az PowerShell (ale bez poświadczeń)
+- Inside **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** znajduje się kilka `.bin` plików z **access tokens**, ID tokens i informacjami o koncie zaszyfrowanymi za pomocą DPAPI użytkownika.
+- Można znaleźć więcej **access tokens** w plikach `.tbres` wewnątrz **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`**, które zawierają base64 zaszyfrowane za pomocą DPAPI z access tokens.
+- W Linux i macOS można uzyskać **access tokens, refresh tokens and id tokens** z Az PowerShell (jeśli używane), uruchamiając `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
+- W Windows to generuje tylko id tokens.
+- Można sprawdzić, czy Az PowerShell był używany w Linux i macSO, sprawdzając, czy istnieje `$HOME/.local/share/.IdentityService/` (choć zawarte pliki są puste i bezużyteczne)
+- Jeśli użytkownik jest **logged inside Azure with the browser**, zgodnie z tym [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) można uruchomić flow uwierzytelniania z **przekierowaniem na localhost**, sprawić, by przeglądarka automatycznie zatwierdziła logowanie i otrzymać refresh token. Zauważ, że tylko kilka aplikacji FOCI pozwala na redirect do localhost (np. az cli lub moduł powershell), więc te aplikacje muszą być dozwolone.
+- Inną opcją opisaną na blogu jest użycie narzędzia [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow), które może użyć dowolnej aplikacji, ponieważ **pobierze OAuth code, a następnie uzyska refresh token z tytułu końcowej strony auth** używając redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient`.
 
-## Odniesienia
+## References
 
 - [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
 - [https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md](https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md)