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 - Tokens & öffentliche Anwendungen
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Grundlegende Informationen
 
-Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattform von Microsoft, die als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager dient. Azure AD implementiert das OAuth 2.0 Autorisierungsframework und das OpenID Connect (OIDC) Authentifizierungsprotokoll, um den Zugriff auf Ressourcen zu verwalten.
+Entra ID ist Microsofts cloudbasierte Identitäts- und Zugriffsverwaltung (IAM)-Plattform und dient als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager. Azure AD implementiert das OAuth 2.0-Authorisierungsframework und das OpenID Connect (OIDC)-Authentifizierungsprotokoll, um den Zugriff auf Ressourcen zu verwalten.
 
 ### OAuth
 
-**Wichtige Teilnehmer in OAuth 2.0:**
+**Wesentliche Teilnehmer in OAuth 2.0:**
 
-1. **Ressourcenserver (RS):** Schützt Ressourcen, die dem Ressourcenbesitzer gehören.
-2. **Ressourcenbesitzer (RO):** Typischerweise ein Endbenutzer, der die geschützten Ressourcen besitzt.
-3. **Client-Anwendung (CA):** Eine Anwendung, die im Namen des Ressourcenbesitzers Zugriff auf Ressourcen anfordert.
-4. **Autorisierungsserver (AS):** Gibt Zugriffstoken an Client-Anwendungen aus, nachdem diese authentifiziert und autorisiert wurden.
+1. **Resource Server (RS):** Schützt Ressourcen, die dem Resource Owner gehören.
+2. **Resource Owner (RO):** Typischerweise ein Endbenutzer, der die geschützten Ressourcen besitzt.
+3. **Client Application (CA):** Eine Anwendung, die im Auftrag des Resource Owner Zugriff auf Ressourcen anfordert.
+4. **Authorization Server (AS):** Gibt Access Tokens an Client-Anwendungen aus, nachdem diese authentifiziert und autorisiert wurden.
 
 **Scopes und Zustimmung:**
 
-- **Scopes:** Granulare Berechtigungen, die auf dem Ressourcenserver definiert sind und Zugriffslevel spezifizieren.
-- **Zustimmung:** Der Prozess, durch den ein Ressourcenbesitzer einer Client-Anwendung die Erlaubnis erteilt, auf Ressourcen mit bestimmten Scopes zuzugreifen.
+- **Scopes:** Granulare Berechtigungen, die auf dem Resource Server definiert sind und Zugangsebenen festlegen.
+- **Consent / Zustimmung:** Der Prozess, durch den ein Resource Owner einer Client-Anwendung erlaubt, mit bestimmten Scopes auf Ressourcen zuzugreifen.
 
-**Microsoft 365 Integration:**
+**Microsoft 365-Integration:**
 
-- Microsoft 365 nutzt Azure AD für IAM und besteht aus mehreren "First-Party" OAuth-Anwendungen.
-- Diese Anwendungen sind tief integriert und haben oft voneinander abhängige Dienstbeziehungen.
-- Um die Benutzererfahrung zu vereinfachen und die Funktionalität aufrechtzuerhalten, gewährt Microsoft diesen First-Party-Anwendungen "implizite Zustimmung" oder "Vorab-Zustimmung".
-- **Implizite Zustimmung:** Bestimmte Anwendungen erhalten automatisch **Zugriff auf spezifische Scopes ohne ausdrückliche Genehmigung des Benutzers oder Administrators**.
-- Diese vorab genehmigten Scopes sind typischerweise sowohl für Benutzer als auch für Administratoren verborgen, was sie in den Standardverwaltungsoberflächen weniger sichtbar macht.
+- Microsoft 365 nutzt Azure AD für IAM und besteht aus mehreren "first-party" OAuth-Anwendungen.
+- Diese Anwendungen sind tief integriert und haben oft voneinander abhängige Service-Beziehungen.
+- Um die Benutzererfahrung zu vereinfachen und die Funktionalität zu erhalten, gewährt Microsoft diesen First-Party-Anwendungen "implied consent" bzw. "pre-consent".
+- **Implied Consent / Implizite Zustimmung:** Bestimmten Anwendungen wird automatisch **Zugriff auf spezifische Scopes gewährt, ohne explizite Zustimmung des Benutzers oder Administrators**.
+- Diese vorab genehmigten Scopes sind typischerweise sowohl für Benutzer als auch Administratoren verborgen und somit in Standardverwaltungsoberflächen weniger sichtbar.
 
-**Client-Anwendungstypen:**
+**Typen von Client-Anwendungen:**
 
-1. **Vertrauliche Clients:**
+1. **Confidential Clients:**
 - Besitzen eigene Anmeldeinformationen (z. B. Passwörter oder Zertifikate).
-- Können sich **sicher beim Autorisierungsserver authentifizieren**.
-2. **Öffentliche Clients:**
-- Haben keine einzigartigen Anmeldeinformationen.
-- Können sich nicht sicher beim Autorisierungsserver authentifizieren.
-- **Sicherheitsimplikation:** Ein Angreifer kann eine öffentliche Client-Anwendung nachahmen, wenn er Token anfordert, da es keinen Mechanismus gibt, mit dem der Autorisierungsserver die Legitimität der Anwendung überprüfen kann.
+- Können sich gegenüber dem Authorization Server **sicher authentifizieren**.
+2. **Public Clients:**
+- Haben keine eindeutigen Anmeldeinformationen.
+- Können sich nicht sicher beim Authorization Server authentifizieren.
+- **Sicherheitsimplikation:** Ein Angreifer kann eine Public Client-Anwendung bei Tokenanfragen nachahmen, da es keinen Mechanismus gibt, mit dem der Authorization Server die Legitimität der Anwendung verifizieren kann.
 
-## Authentifizierungstoken
+## Authentifizierungs-Token
 
-Es gibt **drei Arten von Tokens**, die in OIDC verwendet werden:
+Es gibt **drei Arten von Token**, die in OIDC verwendet werden:
 
-- [**Zugriffstoken**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Der Client präsentiert dieses Token dem Ressourcenserver, um **auf Ressourcen zuzugreifen**. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Ressource verwendet werden und **kann bis zum Ablauf nicht widerrufen werden** - das sind standardmäßig 1 Stunde.
-- **ID-Tokens**: Der Client erhält dieses **Token vom Autorisierungsserver**. Es enthält grundlegende Informationen über den Benutzer. Es ist **an eine spezifische Kombination aus Benutzer und Client gebunden**.
-- **Aktualisierungstoken**: Werden dem Client zusammen mit dem Zugriffstoken bereitgestellt. Wird verwendet, um **neue Zugriffs- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die Standardablaufzeit beträgt **90 Tage** für inaktive Aktualisierungstoken und **keine Ablaufzeit für aktive Tokens** (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstoken zu erhalten).
-- Ein Aktualisierungstoken sollte an ein **`aud`**, an einige **Scopes** und an einen **Mandanten** gebunden sein und sollte nur in der Lage sein, Zugriffstoken für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei **FOCI-Anwendungstoken**.
-- Ein Aktualisierungstoken ist verschlüsselt und nur Microsoft kann es entschlüsseln.
-- Das Erhalten eines neuen Aktualisierungstokens widerruft das vorherige Aktualisierungstoken nicht.
+- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Der Client präsentiert dieses Token dem Resource Server, um **auf Ressourcen zuzugreifen**. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Resource verwendet werden und **kann nicht vor Ablauf widerrufen werden** — standardmäßig ist das Ablaufdatum 1 Stunde.
+- **ID Tokens**: Dieses Token erhält der Client vom Authorization Server. Es enthält grundlegende Informationen über den Benutzer. Es ist **an eine spezifische Kombination aus Benutzer und Client gebunden**.
+- **Refresh Tokens**: Werden dem Client zusammen mit dem Access Token bereitgestellt. Werden verwendet, um **neue Access- und ID-Tokens zu erhalten**. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Standardmäßiges Ablaufverhalten: **90 Tage** für inaktive Refresh Tokens und **kein Ablauf** für aktive Tokens (aus einem Refresh-Token kann es möglich sein, neue Refresh-Tokens zu erhalten).
+- Ein Refresh Token sollte an ein **`aud`**, an gewisse **scopes** und an einen **tenant** gebunden sein und sollte nur in der Lage sein, Access Tokens für dieses aud, diese scopes (und nicht mehr) und diesen tenant zu erzeugen. Dies ist jedoch **nicht** der Fall bei **FOCI applications tokens**.
+- Ein Refresh Token ist verschlüsselt und nur Microsoft kann es entschlüsseln.
+- Das Erhalten eines neuen Refresh Tokens widerruft das vorherige Refresh Token nicht.
 
 > [!WARNING]
-> Informationen für **bedingten Zugriff** sind **innerhalb des JWT gespeichert**. Wenn Sie also das **Token von einer erlaubten IP-Adresse anfordern**, wird diese **IP** im Token **gespeichert**, und dann können Sie dieses Token von einer **nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen**.
+> Informationen für **conditional access** werden **im JWT gespeichert**. Wenn du also das **Token von einer erlaubten IP-Adresse anforderst**, wird diese **IP** im Token **gespeichert** und dann kannst du dieses Token von einer **nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen**.
 
-### Zugriffstoken "aud"
+### Access Tokens "aud"
 
-Das im "aud"-Feld angegebene Feld ist der **Ressourcenserver** (die Anwendung), die verwendet wird, um die Anmeldung durchzuführen.
+Der im "aud"-Feld angegebene Wert ist der **Resource Server** (die Anwendung), der für die Anmeldung verwendet wird.
 
-Der Befehl `az account get-access-token --resource-type [...]` unterstützt die folgenden Typen, und jeder von ihnen wird ein spezifisches "aud" im resultierenden Zugriffstoken hinzufügen:
+Der Befehl `az account get-access-token --resource-type [...]` unterstützt die folgenden Typen und jeder von ihnen wird ein spezifisches "aud" im resultierenden Access Token hinzufügen:
 
 > [!CAUTION]
-> Beachten Sie, dass die folgenden nur die von `az account get-access-token` unterstützten APIs sind, es gibt jedoch weitere.
+> Beachte, dass die folgenden nur die APIs sind, die von `az account get-access-token` unterstützt werden — es gibt noch mehr.
 
 <details>
 
-<summary>aud Beispiele</summary>
+<summary>aud examples</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die veraltete Azure AD Graph API (abgekündigt) zuzugreifen, die Anwendungen das Lesen und Schreiben von Verzeichnisdaten in Azure Active Directory (Azure AD) ermöglicht.
+- **aad-graph (Azure Active Directory Graph API)**: Wird verwendet, um auf die legacy Azure AD Graph API (deprecated) zuzugreifen, die Anwendungen das Lesen und Schreiben von Verzeichnisdaten in Azure Active Directory (Azure AD) ermöglicht.
 - `https://graph.windows.net/`
 
-* **arm (Azure Resource Manager)**: Wird verwendet, um Azure-Ressourcen über die Azure Resource Manager API zu verwalten. Dazu gehören Operationen wie das Erstellen, Aktualisieren und Löschen von Ressourcen wie virtuellen Maschinen, Speicherkonten und mehr.
-- `https://management.core.windows.net/ oder https://management.azure.com/`
+* **arm (Azure Resource Manager)**: Wird verwendet, um Azure-Ressourcen über die Azure Resource Manager API zu verwalten. Dazu gehören Operationen wie Erstellen, Aktualisieren und Löschen von Ressourcen wie virtuellen Maschinen, Storage Accounts und mehr.
+- `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Wird verwendet, um auf Azure Batch zuzugreifen, einen Dienst, der groß angelegte parallele und hochleistungsfähige Rechenanwendungen effizient in der Cloud ermöglicht.
+- **batch (Azure Batch Services)**: Wird verwendet, um auf Azure Batch zuzugreifen, einen Dienst, der großskalige parallele und High-Performance-Computing-Anwendungen effizient in der Cloud ermöglicht.
 - `https://batch.core.windows.net/`
 
-* **data-lake (Azure Data Lake Storage)**: Wird verwendet, um mit Azure Data Lake Storage Gen1 zu interagieren, einem skalierbaren Datenlager- und Analysedienst.
+* **data-lake (Azure Data Lake Storage)**: Wird verwendet, um mit Azure Data Lake Storage Gen1 zu interagieren, einem skalierbaren Datenspeicher- und Analyse-Dienst.
 - `https://datalake.azure.net/`
 
 - **media (Azure Media Services)**: Wird verwendet, um auf Azure Media Services zuzugreifen, die cloudbasierte Medienverarbeitungs- und Bereitstellungsdienste für Video- und Audioinhalte bereitstellen.
 - `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Wird verwendet, um auf die Microsoft Graph API zuzugreifen, den einheitlichen Endpunkt für Microsoft 365-Daten. Es ermöglicht den Zugriff auf Daten und Einblicke aus Diensten wie Azure AD, Office 365, Enterprise Mobility und Sicherheitsdiensten.
+* **ms-graph (Microsoft Graph API)**: Wird verwendet, um auf die Microsoft Graph API zuzugreifen, den einheitlichen Endpunkt für Daten der Microsoft 365-Dienste. Ermöglicht den Zugriff auf Daten und Erkenntnisse aus Diensten wie Azure AD, Office 365, Enterprise Mobility und Security Services.
 - `https://graph.microsoft.com`
 
-- **oss-rdbms (Azure Open Source Relational Databases)**: Wird verwendet, um auf Azure-Datenbankdienste für Open-Source-Relationale Datenbank-Engines wie MySQL, PostgreSQL und MariaDB zuzugreifen.
+- **oss-rdbms (Azure Open Source Relational Databases)**: Wird verwendet, um auf Azure Database Services für Open-Source-Relationaldatenbank-Engines wie MySQL, PostgreSQL und MariaDB zuzugreifen.
 - `https://ossrdbms-aad.database.windows.net`
 
 </details>
 
-### Zugriffstoken Scopes "scp"
+### Access Tokens Scopes "scp"
 
-Der Scope eines Zugriffstokens wird im scp-Schlüssel innerhalb des Zugriffstoken-JWT gespeichert. Diese Scopes definieren, auf was das Zugriffstoken Zugriff hat.
+Der Scope eines Access Tokens wird im scp-Schlüssel innerhalb des Access Token JWT gespeichert. Diese Scopes legen fest, worauf das Access Token Zugriff hat.
 
-Wenn ein JWT berechtigt ist, eine spezifische API zu kontaktieren, aber **nicht den Scope** hat, um die angeforderte Aktion auszuführen, **kann es die Aktion nicht mit diesem JWT ausführen**.
+Wenn ein JWT berechtigt ist, eine bestimmte API zu kontaktieren, aber **nicht den Scope** besitzt, um die angeforderte Aktion auszuführen, wird es **die Aktion mit diesem JWT nicht ausführen können**.
 
-### Beispiel zum Abrufen von Aktualisierungs- und Zugriffstoken
+### Get refresh & access token example
 ```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"]
@@ -144,32 +144,31 @@ scopes=["https://graph.microsoft.com/.default"],
 )
 pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
-### Andere Zugriffs-Token-Felder
+### Andere access token-Felder
 
-- **appid**: Anwendungs-ID, die zur Generierung des Tokens verwendet wird
-- **appidacr**: Der Application Authentication Context Class Reference gibt an, wie der Client authentifiziert wurde; für einen öffentlichen Client ist der Wert 0, und wenn ein Client-Geheimnis verwendet wird, ist der Wert 1
-- **acr**: Der Authentication Context Class Reference-Anspruch ist "0", wenn die Authentifizierung des Endbenutzers die Anforderungen von ISO/IEC 29115 nicht erfüllt hat.
-- **amr**: Die Authentifizierungsmethode gibt an, wie das Token authentifiziert wurde. Ein Wert von „pwd“ zeigt an, dass ein Passwort verwendet wurde.
-- **groups**: Gibt die Gruppen an, in denen das Principal Mitglied ist.
-- **iss**: Der Aussteller identifiziert den Sicherheits-Token-Dienst (STS), der das Token generiert hat. z.B. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (die uuid ist die Mandanten-ID)
-- **oid**: Die Objekt-ID des Principals
-- **tid**: Mandanten-ID
-- **iat, nbf, exp**: Ausgestellt am (wann es ausgestellt wurde), Nicht vor (kann vor dieser Zeit nicht verwendet werden, normalerweise derselbe Wert wie iat), Ablaufzeit.
+- **appid**: Application-ID, die zur Generierung des token verwendet wurde
+- **appidacr**: Die Application Authentication Context Class Reference gibt an, wie der client authentifiziert wurde; für einen public client ist der Wert 0, und wenn ein client secret verwendet wird, ist der Wert 1
+- **acr**: Die Authentication Context Class Reference-Claim ist "0", wenn die Endbenutzer-Authentifizierung die Anforderungen von ISO/IEC 29115 nicht erfüllt hat.
+- **amr**: Das Authentication method-Feld gibt an, wie das token authentifiziert wurde. Ein Wert von “pwd” zeigt an, dass ein Passwort verwendet wurde.
+- **groups**: Gibt die Gruppen an, in denen das principal Mitglied ist.
+- **iss**: Das iss-Feld identifiziert den security token service (STS), der das token erzeugt hat. z. B. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (die uuid ist die tenant ID)
+- **oid**: Die object ID des principal
+- **tid**: Tenant ID
+- **iat, nbf, exp**: Ausstellungszeitpunkt (wann es ausgestellt wurde), Not before (kann vor diesem Zeitpunkt nicht verwendet werden, normalerweise derselbe Wert wie iat), Ablaufzeit.
 
+## FOCI Tokens Privilege Escalation
 
-## FOCI-Token Privilegieneskalation
+Vorher wurde erwähnt, dass refresh tokens an die **scopes** gebunden sein sollten, mit denen sie generiert wurden, an die **application** und den **tenant**, für die sie generiert wurden. Wenn eine dieser Grenzen durchbrochen wird, ist es möglich, Privilegien zu eskalieren, da es möglich wird, access tokens für andere Ressourcen und tenants zu erzeugen, auf die der Benutzer Zugriff hat, und mit mehr scopes, als ursprünglich vorgesehen.
 
-Früher wurde erwähnt, dass Refresh-Token an die **Scopes** gebunden sein sollten, mit denen sie generiert wurden, an die **Anwendung** und den **Mandanten**, für die sie generiert wurden. Wenn eine dieser Grenzen überschritten wird, ist es möglich, Privilegien zu eskalieren, da es möglich sein wird, Zugriffstoken für andere Ressourcen und Mandanten zu generieren, auf die der Benutzer Zugriff hat, und mit mehr Scopes, als ursprünglich beabsichtigt.
+Außerdem ist **dies mit allen refresh tokens möglich** in der [Microsoft identity platform] (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google), weil, wie die [**docs**] erwähnen: "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."
 
-Darüber hinaus **ist dies mit allen Refresh-Token** in der [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra-Konten, Microsoft-Persönliche Konten und soziale Konten wie Facebook und Google) möglich, da die [**Dokumentation**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) erwähnt: "Refresh-Token sind an eine Kombination aus Benutzer und Client gebunden, aber **nicht an eine Ressource oder einen Mandanten gebunden**. Ein Client kann ein Refresh-Token verwenden, um Zugriffstoken **über jede Kombination von Ressource und Mandant** zu erwerben, für die er die Berechtigung hat. Refresh-Token sind verschlüsselt und nur die Microsoft identity platform kann sie lesen."
+Beachte außerdem, dass FOCI applications öffentliche Anwendungen sind, daher **no secret is needed** to authenticate to the server.
 
-Darüber hinaus beachten Sie, dass die FOCI-Anwendungen öffentliche Anwendungen sind, sodass **kein Geheimnis erforderlich ist**, um sich beim Server zu authentifizieren.
+Dann bekannte FOCI-Clients, die in der [**original research**] berichtet wurden, können [**found here**].
 
-Bekannte FOCI-Clients, die in der [**ursprünglichen Forschung**](https://github.com/secureworks/family-of-client-ids-research/tree/main) berichtet wurden, können [**hier gefunden werden**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
+### Anderen scope anfordern
 
-### Anderen Scope abrufen
-
-Im Folgenden wird im vorherigen Beispielcode ein neues Token für einen anderen Scope angefordert:
+Im Anschluss an das vorherige Beispielcode wird in diesem Code ein neues token für einen anderen scope angefordert:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -186,7 +185,7 @@ scopes=[
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-### Verschiedene Clients und Scopes abrufen
+### Einen anderen client und scopes erhalten
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
@@ -202,25 +201,26 @@ scopes=["https://graph.microsoft.com/.default"],
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
-## Wo man Tokens findet
+## Wo man tokens findet
 
-Aus der Perspektive eines Angreifers ist es sehr interessant zu wissen, wo es möglich ist, Zugriffs- und Aktualisierungstokens zu finden, wenn beispielsweise der PC eines Opfers kompromittiert ist:
+Aus der Perspektive eines Angreifers ist es sehr interessant zu wissen, wo man z. B. access und refresh tokens finden kann, wenn der PC eines Opfers kompromittiert wurde:
 
 - In **`<HOME>/.Azure`**
-- **`azureProfile.json`** enthält Informationen über angemeldete Benutzer aus der Vergangenheit
-- **`clouds.config` enthält** Informationen über Abonnements
-- **`service_principal_entries.json`** enthält Anwendungsanmeldeinformationen (Mandanten-ID, Clients und Geheimnis). Nur in Linux & macOS
-- **`msal_token_cache.json`** enthält Zugriffs- und Aktualisierungstokens. Nur in Linux & macOS
-- **`service_principal_entries.bin`** und **`msal_token_cache.bin`** werden in Windows verwendet und sind mit DPAPI verschlüsselt
-- **`msal_http_cache.bin`** ist ein Cache von HTTP-Anfragen
-- Lade es: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
-- **`AzureRmContext.json`** enthält Informationen über frühere Anmeldungen mit Az PowerShell (aber keine Anmeldeinformationen)
-- In **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** befinden sich mehrere `.bin`-Dateien mit **Zugriffstokens**, ID-Tokens und Kontoinformationen, die mit dem DPAPI des Benutzers verschlüsselt sind.
-- Es ist möglich, weitere **Zugriffstokens** in den `.tbres`-Dateien innerhalb von **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** zu finden, die ein mit DPAPI verschlüsseltes base64 mit Zugriffstokens enthalten.
-- In Linux und macOS können Sie **Zugriffstokens, Aktualisierungstokens und ID-Tokens** von Az PowerShell (wenn verwendet) erhalten, indem Sie `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` ausführen.
-- In Windows generiert dies nur ID-Tokens.
-- Es ist möglich zu sehen, ob Az PowerShell in Linux und macOS verwendet wurde, indem überprüft wird, ob `$HOME/.local/share/.IdentityService/` existiert (obwohl die enthaltenen Dateien leer und nutzlos sind).
-- Wenn der Benutzer **im Browser bei Azure angemeldet ist**, ist es laut diesem [**Beitrag**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) möglich, den Authentifizierungsfluss mit einer **Weiterleitung zu localhost** zu starten, den Browser automatisch die Anmeldung autorisieren zu lassen und das Aktualisierungstoken zu erhalten. Beachten Sie, dass es nur wenige FOCI-Anwendungen gibt, die eine Weiterleitung zu localhost erlauben (wie az cli oder das PowerShell-Modul), sodass diese Anwendungen erlaubt sein müssen.
+- **`azureProfile.json`** enthält Informationen über zuvor angemeldete Benutzer
+- **`clouds.config contains`** Informationen über Abonnements
+- **`service_principal_entries.json`** enthält Anwendungs-Credentials (tenant id, clients und secret). Nur unter Linux & macOS
+- **`msal_token_cache.json`** enthält access tokens und refresh tokens. Nur unter Linux & macOS
+- **`service_principal_entries.bin`** und msal_token_cache.bin werden unter Windows verwendet und sind mit DPAPI verschlüsselt
+- **`msal_http_cache.bin`** ist ein Cache für HTTP-Anfragen
+- Laden: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
+- **`AzureRmContext.json`** enthält Informationen über vorherige Anmeldungen mit Az PowerShell (aber keine Anmeldeinformationen)
+- In **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** befinden sich mehrere `.bin`-Dateien mit **access tokens**, ID tokens und Kontoinformationen, verschlüsselt mit der DPAPI des Benutzers.
+- Es ist möglich, weitere **access tokens** in den `.tbres`-Dateien im Ordner **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** zu finden, die eine Base64 (mit DPAPI verschlüsselt) enthalten, die access tokens beinhaltet.
+- Unter Linux und macOS kann man **access tokens, refresh tokens und id tokens** aus Az PowerShell (falls verwendet) bekommen, indem man `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` ausführt
+- Unter Windows erzeugt das nur id tokens.
+- Man kann prüfen, ob Az PowerShell unter Linux und macOS verwendet wurde, indem man kontrolliert, ob `$HOME/.local/share/.IdentityService/` existiert (auch wenn die enthaltenen Dateien leer und nutzlos sind)
+- Wenn der Benutzer im Browser bei Azure angemeldet ist, kann man laut diesem [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) den Authentifizierungsfluss mit einer **Weiterleitung auf localhost** starten, das Browserfenster die Anmeldung automatisch autorisieren lassen und das refresh token empfangen. Beachte, dass nur wenige FOCI-Anwendungen Redirects auf localhost erlauben (wie az cli oder das PowerShell-Modul), daher müssen diese Anwendungen zugelassen sein.
+- Eine weitere im Blog erklärte Option ist die Verwendung des Tools [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow), das jede Anwendung verwenden kann, weil es den OAuth-Code erhält, um dann mithilfe des Titels der finalen Authentifizierungsseite ein refresh token zu bekommen, unter Verwendung der Redirect-URI `https://login.microsoftonline.com/common/oauth2/nativeclient`.
 
 ## Referenzen