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

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

@@ -4,59 +4,59 @@
 
 ## Basic Information
 
-Entra ID माइक्रोसॉफ्ट का क्लाउड-आधारित पहचान और पहुंच प्रबंधन (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसी सेवाओं के लिए मौलिक प्रमाणीकरण और प्राधिकरण प्रणाली के रूप में कार्य करता है। Azure AD OAuth 2.0 प्राधिकरण ढांचे और OpenID Connect (OIDC) प्रमाणीकरण प्रोटोकॉल को संसाधनों तक पहुंच प्रबंधित करने के लिए लागू करता है।
+Entra ID Microsoft का क्लाउड-आधारित identity और access management (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसे सेवाओं के लिए foundational authentication और authorization सिस्टम के रूप में कार्य करता है। Azure AD OAuth 2.0 authorization framework और OpenID Connect (OIDC) authentication protocol को लागू करता है ताकि resources तक एक्सेस को मैनेज किया जा सके।
 
 ### OAuth
 
-**OAuth 2.0 में मुख्य प्रतिभागी:**
+**OAuth 2.0 में प्रमुख प्रतिभागी:**
 
-1. **Resource Server (RS):** संसाधनों की रक्षा करता है जो संसाधन मालिक के पास हैं।
-2. **Resource Owner (RO):** आमतौर पर एक अंतिम उपयोगकर्ता जो संरक्षित संसाधनों का मालिक होता है।
-3. **Client Application (CA):** एक एप्लिकेशन जो संसाधन मालिक की ओर से संसाधनों तक पहुंच प्राप्त करने का प्रयास करता है।
-4. **Authorization Server (AS):** प्रमाणीकरण और प्राधिकरण के बाद क्लाइंट एप्लिकेशनों को एक्सेस टोकन जारी करता है।
+1. **Resource Server (RS):** resource owner के द्वारा स्वामित्व वाले resources की सुरक्षा करता है।
+2. **Resource Owner (RO):** आमतौर पर एक end-user जो protected resources का मालिक होता है।
+3. **Client Application (CA):** एक application जो resource owner की ओर से resources तक पहुंच चाहता है।
+4. **Authorization Server (AS):** client applications को authenticate और authorize करने के बाद access tokens जारी करता है।
 
 **Scopes और Consent:**
 
-- **Scopes:** संसाधन सर्वर पर परिभाषित सूक्ष्म अनुमतियाँ जो पहुँच स्तर निर्दिष्ट करती हैं।
-- **Consent:** वह प्रक्रिया जिसके द्वारा एक संसाधन मालिक एक क्लाइंट एप्लिकेशन को विशिष्ट स्कोप के साथ संसाधनों तक पहुँच प्राप्त करने की अनुमति देता है।
+- **Scopes:** resource server पर परिभाषित granular permissions जो access स्तरों को निर्दिष्ट करते हैं।
+- **Consent:** वह प्रक्रिया जिसके द्वारा resource owner किसी client application को विशिष्ट scopes के साथ resources तक पहुंच का permission देता है।
 
 **Microsoft 365 Integration:**
 
-- Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और इसमें कई "पहली-पार्टी" OAuth एप्लिकेशन शामिल हैं।
-- ये एप्लिकेशन गहराई से एकीकृत हैं और अक्सर आपस में निर्भर सेवा संबंध होते हैं।
-- उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, माइक्रोसॉफ्ट इन पहली-पार्टी एप्लिकेशनों को "अर्थित सहमति" या "पूर्व-सहमति" प्रदान करता है।
-- **Implied Consent:** कुछ एप्लिकेशनों को स्पष्ट उपयोगकर्ता या प्रशासक अनुमोदन के बिना विशिष्ट स्कोप तक पहुँच **स्वचालित रूप से प्रदान की जाती है**।
-- ये पूर्व-सहमति वाले स्कोप आमतौर पर उपयोगकर्ताओं और प्रशासकों दोनों से छिपे होते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।
+- Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और यह कई "first-party" OAuth applications से बना है।
+- ये applications गहरे तरीके से एकीकृत होते हैं और अक्सर आपसी सेवा-निर्भर संबंध रखते हैं।
+- उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, Microsoft इन first-party applications को "implied consent" या "pre-consent" प्रदान करता है।
+- **निहित सहमति (Implied Consent):** कुछ applications को स्वचालित रूप से **विशिष्ट scopes तक पहुंच बिना स्पष्ट user या administrator अनुमोदन के प्रदान की जाती है**।
+- ये pre-consented scopes आमतौर पर users और administrators दोनों से छिपे होते हैं, जिससे वे standard management interfaces में कम दिखाई देते हैं।
 
-**Client Application Types:**
+**Client Application प्रकार:**
 
 1. **Confidential Clients:**
-- अपने स्वयं के क्रेडेंशियल्स (जैसे, पासवर्ड या प्रमाणपत्र) रखते हैं।
-- प्राधिकरण सर्वर के लिए **सुरक्षित रूप से प्रमाणीकरण** कर सकते हैं।
+- अपनी खुद की credentials (जैसे passwords या certificates) रखते हैं।
+- authorization server को **securely authenticate** कर सकते हैं।
 2. **Public Clients:**
-- अद्वितीय क्रेडेंशियल्स नहीं होते हैं।
-- प्राधिकरण सर्वर के लिए सुरक्षित रूप से प्रमाणीकरण नहीं कर सकते हैं।
-- **Security Implication:** एक हमलावर टोकन मांगते समय एक सार्वजनिक क्लाइंट एप्लिकेशन का अनुकरण कर सकता है, क्योंकि प्राधिकरण सर्वर के लिए एप्लिकेशन की वैधता की पुष्टि करने का कोई तंत्र नहीं है।
+- अलग से unique credentials नहीं रखते।
+- authorization server को securely authenticate नहीं कर पाते।
+- **Security Implication:** एक attacker public client application का नकल कर सकता है जब वह tokens का अनुरोध कर रहा हो, क्योंकि authorization server के पास application की वैधता सत्यापित करने का कोई механизм नहीं होता।
 
 ## Authentication Tokens
 
-OIDC में **तीन प्रकार के टोकन** होते हैं:
+OIDC में उपयोग होने वाले **तीन प्रकार के टोकन** हैं:
 
-- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट इस टोकन को संसाधन सर्वर को **संसाधनों तक पहुँचने** के लिए प्रस्तुत करता है। इसे केवल उपयोगकर्ता, क्लाइंट और संसाधन के विशिष्ट संयोजन के लिए उपयोग किया जा सकता है और **समाप्ति तक रद्द नहीं किया जा सकता** - जो कि डिफ़ॉल्ट रूप से 1 घंटा है।
-- **ID Tokens**: क्लाइंट को यह **टोकन प्राधिकरण सर्वर से प्राप्त होता है**। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह **उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है**।
-- **Refresh Tokens**: क्लाइंट को एक्सेस टोकन के साथ प्रदान किया जाता है। इसका उपयोग **नए एक्सेस और ID टोकन प्राप्त करने** के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। निष्क्रिय रिफ्रेश टोकनों के लिए डिफ़ॉल्ट समाप्ति **90 दिन** है और सक्रिय टोकनों के लिए **कोई समाप्ति नहीं** है (एक रिफ्रेश टोकन से नए रिफ्रेश टोकन प्राप्त करना संभव है)।
-- एक रिफ्रेश टोकन को एक **`aud`** , कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और इसे केवल उस aud, scopes (और अधिक नहीं) और tenant के लिए एक्सेस टोकन उत्पन्न करने में सक्षम होना चाहिए। हालाँकि, यह **FOCI एप्लिकेशन टोकन** के साथ ऐसा नहीं है।
-- एक रिफ्रेश टोकन एन्क्रिप्टेड होता है और केवल माइक्रोसॉफ्ट इसे डिक्रिप्ट कर सकता है।
-- नया रिफ्रेश टोकन प्राप्त करने से पिछले रिफ्रेश टोकन को रद्द नहीं किया जाता है।
+- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** क्लाइंट इस टोकन को resource server के पास resources तक पहुंचने के लिए प्रस्तुत करता है। यह केवल एक specific combination of user, client, और resource के लिए उपयोग किया जा सकता है और expiry तक **revoke नहीं किया जा सकता** — डिफ़ॉल्ट रूप से यह 1 घंटे है।
+- **ID Tokens**: यह टोकन client को authorization server से मिलता है। इसमें user के बारे में basic जानकारी होती है। यह **specific combination of user और client** के लिए bound होता है।
+- **Refresh Tokens**: access token के साथ client को प्रदान किए जाते हैं। इनका उपयोग **नए access और ID tokens प्राप्त करने** के लिए किया जाता है। यह एक specific combination of user और client के लिए bound होता है और revoke किया जा सकता है। inactive refresh tokens के लिए डिफ़ॉल्ट expiry **90 days** है और active tokens के लिए **no expiry** (refresh token से नए refresh tokens प्राप्त करना संभव होने पर)।
+- एक refresh token को एक `aud`, कुछ **scopes**, और एक **tenant** से जोड़ा जाना चाहिए और यह केवल उस aud, scopes (और और नहीं) और tenant के लिए access tokens जनरेट करने में सक्षम होना चाहिए। हालाँकि, यह **FOCI applications tokens** के साथ मामला नहीं है।
+- एक refresh token encrypted होता है और केवल Microsoft ही इसे decrypt कर सकता है।
+- नया refresh token प्राप्त करने से पिछले refresh token को revoke नहीं किया जाता।
 
 > [!WARNING]
-> **Conditional access** के लिए जानकारी **JWT** के अंदर **स्टोर** की जाती है। इसलिए, यदि आप **अनुमत IP पते** से **टोकन** का अनुरोध करते हैं, तो वह **IP** टोकन में **स्टोर** किया जाएगा और फिर आप उस टोकन का उपयोग **गैर-अनुमत IP से संसाधनों तक पहुँचने** के लिए कर सकते हैं।
+> **conditional access** की जानकारी **JWT** के अंदर **store** होती है। इसलिए, यदि आप **allowed IP address** से टोकन का अनुरोध करते हैं, तो वह **IP** टोकन में **store** हो जाएगा और फिर आप उस टोकन का उपयोग करके **non-allowed IP** से resources तक access कर सकेंगे।
 
 ### Access Tokens "aud"
 
-"aud" फ़ील्ड में निर्दिष्ट फ़ील्ड वह **resource server** (एप्लिकेशन) है जिसका उपयोग लॉगिन करने के लिए किया जाता है।
+"aud" फील्ड में सूचित किया गया फ़ील्ड वह **resource server** (या application) है जिसका उपयोग login करने के लिए किया गया था।
 
-कमांड `az account get-access-token --resource-type [...]` निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप एक्सेस टोकन में एक विशिष्ट "aud" जोड़ेगा:
+कमांड `az account get-access-token --resource-type [...]` निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप access token में एक specific "aud" जोड़ देगा:
 
 > [!CAUTION]
 > ध्यान दें कि निम्नलिखित केवल `az account get-access-token` द्वारा समर्थित APIs हैं लेकिन और भी हैं।
@@ -65,34 +65,34 @@ OIDC में **तीन प्रकार के टोकन** होते
 
 <summary>aud examples</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: पुराने Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग किया जाता है, जो एप्लिकेशनों को Azure Active Directory (Azure AD) में निर्देशिका डेटा पढ़ने और लिखने की अनुमति देता है।
+- **aad-graph (Azure Active Directory Graph API)**: legacy Azure AD Graph API (deprecated) तक पहुँचने के लिए उपयोग होता है, जो applications को Azure Active Directory (Azure AD) में directory data पढ़ने और लिखने की अनुमति देता है।
 - `https://graph.windows.net/`
 
-* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure संसाधनों का प्रबंधन करने के लिए उपयोग किया जाता है। इसमें वर्चुअल मशीनों, स्टोरेज खातों, और अधिक जैसे संसाधनों को बनाने, अपडेट करने और हटाने जैसी क्रियाएँ शामिल हैं।
+* **arm (Azure Resource Manager)**: Azure Resource Manager API के माध्यम से Azure resources को मैनेज करने के लिए उपयोग होता है। इसमें virtual machines, storage accounts, आदि जैसी resources को बनाना, अपडेट और हटाना शामिल है।
 - `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग किया जाता है, एक सेवा जो क्लाउड में बड़े पैमाने पर समानांतर और उच्च-प्रदर्शन कंप्यूटिंग एप्लिकेशनों को कुशलतापूर्वक सक्षम बनाती है।
+- **batch (Azure Batch Services)**: Azure Batch तक पहुँचने के लिए उपयोग होता है, जो क्लाउड में बड़े पैमाने पर parallel और high-performance computing applications को कुशलतापूर्वक सक्षम करता है।
 - `https://batch.core.windows.net/`
 
-* **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ बातचीत करने के लिए उपयोग किया जाता है, जो एक स्केलेबल डेटा स्टोरेज और एनालिटिक्स सेवा है।
+* **data-lake (Azure Data Lake Storage)**: Azure Data Lake Storage Gen1 के साथ इंटरैक्ट करने के लिए उपयोग होता है, जो एक स्केलेबल डेटा स्टोरेज और analytics सेवा है।
 - `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग किया जाता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित मीडिया प्रसंस्करण और वितरण सेवाएँ प्रदान करता है।
+- **media (Azure Media Services)**: Azure Media Services तक पहुँचने के लिए उपयोग होता है, जो वीडियो और ऑडियो सामग्री के लिए क्लाउड-आधारित मीडिया प्रोसेसिंग और delivery सेवाएं प्रदान करता है।
 - `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग किया जाता है, जो Microsoft 365 सेवाओं के डेटा के लिए एकीकृत एंडपॉइंट है। यह Azure AD, Office 365, Enterprise Mobility, और Security सेवाओं जैसी सेवाओं से डेटा और अंतर्दृष्टि तक पहुँचने की अनुमति देता है।
+* **ms-graph (Microsoft Graph API)**: Microsoft Graph API तक पहुँचने के लिए उपयोग होता है, जो Microsoft 365 सेवाओं के डेटा के लिए unified endpoint है। यह Azure AD, Office 365, Enterprise Mobility, और Security services जैसी सेवाओं से डेटा और insights एक्सेस करने की अनुमति देता है।
 - `https://graph.microsoft.com`
 
-- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL, PostgreSQL, और MariaDB जैसी ओपन-सोर्स रिलेशनल डेटाबेस इंजनों के लिए Azure Database सेवाओं तक पहुँचने के लिए उपयोग किया जाता है।
+- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL, PostgreSQL, और MariaDB जैसे open-source relational database engines के लिए Azure Database सेवाओं तक पहुँचने के लिए उपयोग होता है।
 - `https://ossrdbms-aad.database.windows.net`
 
 </details>
 
 ### Access Tokens Scopes "scp"
 
-एक एक्सेस टोकन का स्कोप एक्सेस टोकन JWT के अंदर scp कुंजी के अंदर स्टोर किया जाता है। ये स्कोप परिभाषित करते हैं कि एक्सेस टोकन को किस चीज़ तक पहुँच प्राप्त है।
+Access token का scope access token JWT के अंदर scp key के भीतर संग्रहीत होता है। ये scopes परिभाषित करते हैं कि access token किस चीज़ तक पहुँच रखता है।
 
-यदि एक JWT को किसी विशिष्ट API से संपर्क करने की अनुमति है लेकिन **अनुरोधित क्रिया** को करने के लिए **स्कोप नहीं है**, तो यह उस JWT के साथ **क्रिया करने में असमर्थ होगा**।
+यदि कोई JWT किसी specific API से संपर्क करने की अनुमति रखता है लेकिन उस अनुरोधित क्रिया को करने के लिए उसके पास आवश्यक scope नहीं है, तो वह JWT उस क्रिया को पूरा नहीं कर पाएगा।
 
 ### Get refresh & access token example
 ```python
@@ -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,31 +144,32 @@ scopes=["https://graph.microsoft.com/.default"],
 )
 pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
-### अन्य एक्सेस टोकन फ़ील्ड
+### Other access token fields
 
-- **appid**: टोकन उत्पन्न करने के लिए उपयोग किया जाने वाला एप्लिकेशन आईडी
-- **appidacr**: एप्लिकेशन ऑथेंटिकेशन कॉन्टेक्स्ट क्लास रेफरेंस यह दर्शाता है कि क्लाइंट को कैसे प्रमाणित किया गया था, एक सार्वजनिक क्लाइंट के लिए मान 0 है, और यदि क्लाइंट सीक्रेट का उपयोग किया गया है तो मान 1 है
-- **acr**: ऑथेंटिकेशन कॉन्टेक्स्ट क्लास रेफरेंस क्लेम "0" है जब अंतिम उपयोगकर्ता प्रमाणीकरण ISO/IEC 29115 की आवश्यकताओं को पूरा नहीं करता है।
-- **amr**: ऑथेंटिकेशन विधि यह दर्शाती है कि टोकन को कैसे प्रमाणित किया गया। "pwd" का मान दर्शाता है कि एक पासवर्ड का उपयोग किया गया था।
-- **groups**: उन समूहों को दर्शाता है जहाँ प्रमुख एक सदस्य है।
-- **iss**: मुद्दे उस सुरक्षा टोकन सेवा (STS) की पहचान करता है जिसने टोकन उत्पन्न किया। उदाहरण: https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid टेनेट आईडी है)
-- **oid**: प्रमुख का ऑब्जेक्ट आईडी
-- **tid**: टेनेट आईडी
-- **iat, nbf, exp**: जारी किया गया (जब इसे जारी किया गया), नॉट बिफोर (इस समय से पहले उपयोग नहीं किया जा सकता, आमतौर पर iat के समान मान), समाप्ति समय।
+- **appid**: टोकन जनरेट करने के लिए उपयोग किया गया Application ID
+- **appidacr**: The Application Authentication Context Class Reference यह बताता है कि क्लाइंट कैसे authenticated था; public client के लिए value 0 होता है, और यदि client secret उपयोग किया गया हो तो value 1 होता है
+- **acr**: The Authentication Context Class Reference claim "0" होता है जब end-user authentication ने ISO/IEC 29115 की आवश्यकताओं को पूरा नहीं किया।
+- **amr**: Authentication method यह दिखाता है कि टोकन कैसे authenticated था। “pwd” value यह संकेत देती है कि पासवर्ड का उपयोग हुआ था।
+- **groups**: उन groups को दर्शाता है जिनका principal सदस्य है।
+- **iss**: यह security token service (STS) को पहचानता है जिसने टोकन जनरेट किया। e.g. https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (the uuid is the tenant ID)
+- **oid**: principal का object ID
+- **tid**: Tenant ID
+- **iat, nbf, exp**: Issued at (जब यह जारी किया गया), Not before (इस समय से पहले उपयोग नहीं किया जा सकता, आमतौर पर iat के समान मान), Expiration time.
 
-## FOCI टोकन विशेषाधिकार वृद्धि
 
-पहले उल्लेख किया गया था कि रिफ्रेश टोकन को उन **स्कोप्स** से जोड़ा जाना चाहिए जिनके साथ इसे उत्पन्न किया गया था, **एप्लिकेशन** और **टेनेट** से जिसे इसे उत्पन्न किया गया था। यदि इनमें से कोई भी सीमा टूटती है, तो विशेषाधिकार बढ़ाना संभव है क्योंकि अन्य संसाधनों और टेनेट के लिए एक्सेस टोकन उत्पन्न करना संभव होगा जिन तक उपयोगकर्ता की पहुंच है और जिनमें अधिक स्कोप हैं जितना कि मूल रूप से इरादा किया गया था।
+## FOCI Tokens Privilege Escalation
 
-इसके अलावा, **यह सभी रिफ्रेश टोकन के साथ संभव है** [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra खाते, Microsoft व्यक्तिगत खाते, और Facebook और Google जैसे सामाजिक खाते) में क्योंकि [**दस्तावेज़**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) में उल्लेख किया गया है: "रिफ्रेश टोकन उपयोगकर्ता और क्लाइंट के संयोजन से बंधे होते हैं, लेकिन **किसी संसाधन या टेनेट से बंधे नहीं होते**। एक क्लाइंट रिफ्रेश टोकन का उपयोग करके एक्सेस टोकन प्राप्त कर सकता है **किसी भी संसाधन और टेनेट के संयोजन में** जहाँ इसे ऐसा करने की अनुमति है। रिफ्रेश टोकन एन्क्रिप्टेड होते हैं और केवल Microsoft identity platform इन्हें पढ़ सकता है।"
+पूर्व में कहा गया था कि refresh tokens को जिन **scopes** के साथ इसे जनरेट किया गया था, उस **application** और जिस **tenant** के लिए इसे जनरेट किया गया था उनसे जोड़ा जाना चाहिए। यदि इन किसी भी सीमाओं को तोड़ा जाता है, तो यह संभव है कि privileges escalate हों क्योंकि इससे user के द्वारा access किए जा सकने वाले अन्य resources और tenants के लिए access tokens जनरेट करना संभव हो जाएगा और वे अधिक scopes के साथ हो सकते हैं जितना मूल रूप से निर्धारित था।
 
-इसके अलावा, ध्यान दें कि FOCI एप्लिकेशन सार्वजनिक एप्लिकेशन हैं, इसलिए **सर्वर पर प्रमाणित करने के लिए कोई सीक्रेट की आवश्यकता नहीं है**।
+इसके अलावा, **this is possible with all refresh tokens** in the [Microsoft identity platform] (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) क्योंकि जैसा कि [**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."
 
-फिर ज्ञात FOCI क्लाइंट्स [**मूल शोध**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए हैं [**यहाँ पाया जा सकता है**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv)।
+और ध्यान दें कि FOCI applications public applications हैं, इसलिए server को authenticate करने के लिए **no secret is needed**।
 
-### विभिन्न स्कोप प्राप्त करें
+फिर ज्ञात FOCI clients जो [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) में रिपोर्ट किए गए थे उन्हें [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv) पर देखा जा सकता है।
 
-पिछले उदाहरण कोड के साथ आगे बढ़ते हुए, इस कोड में एक अलग स्कोप के लिए एक नया टोकन अनुरोध किया गया है:
+### Get different scope
+
+Following with the previous example code, in this code it's requested a new token for a different scope:
 ```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)
 ```
-### विभिन्न क्लाइंट और स्कोप प्राप्त करें
+### विभिन्न client और scopes प्राप्त करें
 ```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)
 ```
-## Where to find tokens
+## Tokens कहां मिल सकते हैं
 
-एक हमलावर के दृष्टिकोण से यह जानना बहुत दिलचस्प है कि जब किसी पीसी का शिकार किया जाता है तो एक्सेस और रिफ्रेश टोकन कहां मिल सकते हैं:
+एक हमलावर के दृष्टिकोण से यह जानना बहुत उपयोगी है कि, उदाहरण के लिए जब किसी victim का PC compromised हो, तो कहाँ access और refresh tokens मिल सकते हैं:
 
 - **`<HOME>/.Azure`** के अंदर
-- **`azureProfile.json`** में पिछले लॉग इन उपयोगकर्ताओं की जानकारी होती है
-- **`clouds.config contains`** में सब्सक्रिप्शन की जानकारी होती है
-- **`service_principal_entries.json`** में एप्लिकेशन क्रेडेंशियल्स (टेनेंट आईडी, क्लाइंट और सीक्रेट) होते हैं। केवल Linux और macOS में
-- **`msal_token_cache.json`** में एक्सेस टोकन और रिफ्रेश टोकन होते हैं। केवल Linux और macOS में
-- **`service_principal_entries.bin`** और msal_token_cache.bin Windows में उपयोग किए जाते हैं और DPAPI के साथ एन्क्रिप्टेड होते हैं
-- **`msal_http_cache.bin`** HTTP अनुरोध का कैश है
+- **`azureProfile.json`** में past के logged in users की जानकारी होती है
+- **`clouds.config`** में subscriptions की जानकारी होती है
+- **`service_principal_entries.json`** में applications credentials (tenant id, clients and secret) होते हैं। केवल Linux & macOS पर
+- **`msal_token_cache.json`** में access tokens और refresh tokens होते हैं। केवल Linux & macOS पर
+- **`service_principal_entries.bin`** और **msal_token_cache.bin** Windows में उपयोग होते हैं और DPAPI के साथ encrypted होते हैं
+- **`msal_http_cache.bin`** HTTP request का cache है
 - इसे लोड करें: `with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)`
-- **`AzureRmContext.json`** में Az PowerShell का उपयोग करके पिछले लॉगिन की जानकारी होती है (लेकिन कोई क्रेडेंशियल नहीं)
-- **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** के अंदर कई `.bin` फ़ाइलें होती हैं जिनमें **एक्सेस टोकन**, आईडी टोकन और उपयोगकर्ताओं के DPAPI के साथ एन्क्रिप्टेड खाता जानकारी होती है।
-- **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** के अंदर `.tbres` फ़ाइलों में अधिक **एक्सेस टोकन** मिल सकते हैं, जो DPAPI के साथ एन्क्रिप्टेड बेस64 होते हैं।
-- Linux और macOS में आप Az PowerShell (यदि उपयोग किया गया हो) से **एक्सेस टोकन, रिफ्रेश टोकन और आईडी टोकन** प्राप्त कर सकते हैं, `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"` चलाकर
-- Windows में यह केवल आईडी टोकन उत्पन्न करता है।
-- यह देखना संभव है कि क्या Linux और macOS में Az PowerShell का उपयोग किया गया था, यह जांचकर कि `$HOME/.local/share/.IdentityService/` मौजूद है (हालांकि इसमें मौजूद फ़ाइलें खाली और बेकार हैं)
-- यदि उपयोगकर्ता **ब्राउज़र के माध्यम से Azure में लॉग इन है**, तो इस [**पोस्ट**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) के अनुसार, प्रमाणीकरण प्रवाह शुरू करना संभव है **लोकलहोस्ट पर रीडायरेक्ट** के साथ, ब्राउज़र को स्वचालित रूप से लॉगिन अधिकृत करने के लिए बनाना, और रिफ्रेश टोकन प्राप्त करना। ध्यान दें कि केवल कुछ FOCI एप्लिकेशन हैं जो लोकलहोस्ट पर रीडायरेक्ट की अनुमति देते हैं (जैसे az cli या पावरशेल मॉड्यूल), इसलिए इन एप्लिकेशनों को अनुमति दी जानी चाहिए।
+- **`AzureRmContext.json`** में Az PowerShell का उपयोग करके पिछले logins की जानकारी होती है (लेकिन credentials नहीं)
+- **`C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\*`** के अंदर कई `.bin` फाइलें होती हैं जिनमें users के DPAPI से encrypted **access tokens**, ID tokens और account जानकारी होती है
+- और भी **access tokens** `.tbres` फाइलों में मिल सकते हैं जो **`C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\`** के अंदर होते हैं और जिनमें DPAPI के साथ encrypted base64 में access tokens होते हैं
+- Linux और macOS पर, अगर उपयोग हुआ हो तो Az PowerShell से आप **access tokens, refresh tokens और id tokens** पा सकते हैं: `pwsh -Command "Save-AzContext -Path /tmp/az-context.json"`
+- Windows में यह केवल id tokens जनरेट करता है
+- यह देखना संभव है कि Linux और macSO पर Az PowerShell का उपयोग हुआ था या नहीं यह चेक करके: `$HOME/.local/share/.IdentityService/` मौजूद है या नहीं (हालाँकि उसमें मौजूद फाइलें खाली और बेकार होती हैं)
+- अगर user browser में Azure में logged in है, तो इस [**post**](https://www.infosecnoodle.com/p/obtaining-microsoft-entra-refresh?r=357m16&utm_campaign=post&utm_medium=web) के अनुसार authentication flow को **redirect to localhost** के साथ शुरू करना, browser को स्वतः login authorize करने देना, और resh token प्राप्त करना संभव है। ध्यान दें कि केवल कुछ ही FOCI applications ऐसे हैं जो localhost पर redirect की अनुमति देते हैं (जैसे az cli या the powershell module), इसलिए इन applications की अनुमति होनी चाहिए।
+- ब्लॉग में समझाया गया एक और विकल्प है tool [**BOF-entra-authcode-flow**](https://github.com/sudonoodle/BOF-entra-authcode-flow) का उपयोग करना, जो किसी भी application का उपयोग कर सकता है क्योंकि यह OAuth code प्राप्त कर लेगा और फिर final auth पेज के title से refresh token प्राप्त करेगा, redirect URI के रूप में `https://login.microsoftonline.com/common/oauth2/nativeclient` का उपयोग करते हुए।
 
-## 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)