Az - Tokens & Public Applications

Reading time: 13 minutes

Basic Information

Entra ID माइक्रोसॉफ्ट का क्लाउड-आधारित पहचान और पहुंच प्रबंधन (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसी सेवाओं के लिए मौलिक प्रमाणीकरण और प्राधिकरण प्रणाली के रूप में कार्य करता है। Azure AD OAuth 2.0 प्राधिकरण ढांचे और OpenID Connect (OIDC) प्रमाणीकरण प्रोटोकॉल को संसाधनों तक पहुंच प्रबंधित करने के लिए लागू करता है।

OAuth

OAuth 2.0 में मुख्य प्रतिभागी:

1. Resource Server (RS): संसाधनों की रक्षा करता है जो संसाधन मालिक के पास हैं।
2. Resource Owner (RO): आमतौर पर एक अंतिम उपयोगकर्ता जो संरक्षित संसाधनों का मालिक होता है।
3. Client Application (CA): एक एप्लिकेशन जो संसाधन मालिक की ओर से संसाधनों तक पहुंच प्राप्त करने का प्रयास करता है।
4. Authorization Server (AS): प्रमाणीकरण और प्राधिकरण के बाद क्लाइंट एप्लिकेशनों को एक्सेस टोकन जारी करता है।

Scopes और Consent:

• Scopes: संसाधन सर्वर पर परिभाषित सूक्ष्म अनुमतियाँ जो पहुँच स्तर निर्दिष्ट करती हैं।
• Consent: वह प्रक्रिया जिसके द्वारा एक संसाधन मालिक एक क्लाइंट एप्लिकेशन को विशिष्ट स्कोप के साथ संसाधनों तक पहुँच प्राप्त करने की अनुमति देता है।

Microsoft 365 Integration:

• Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और इसमें कई "पहली-पार्टी" OAuth एप्लिकेशन शामिल हैं।
• ये एप्लिकेशन गहराई से एकीकृत हैं और अक्सर आपस में निर्भर सेवा संबंध होते हैं।
• उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, माइक्रोसॉफ्ट इन पहली-पार्टी एप्लिकेशनों को "अर्थित सहमति" या "पूर्व-सहमति" प्रदान करता है।
• Implied Consent: कुछ एप्लिकेशनों को स्पष्ट उपयोगकर्ता या प्रशासक अनुमोदन के बिना विशिष्ट स्कोप तक पहुँच स्वचालित रूप से प्रदान की जाती है।
• ये पूर्व-सहमति वाले स्कोप आमतौर पर उपयोगकर्ताओं और प्रशासकों दोनों से छिपे होते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।

Client Application Types:

1. Confidential Clients:

• अपने स्वयं के क्रेडेंशियल्स (जैसे, पासवर्ड या प्रमाणपत्र) रखते हैं।
• प्राधिकरण सर्वर के लिए सुरक्षित रूप से प्रमाणीकरण कर सकते हैं।

2. Public Clients:

• अद्वितीय क्रेडेंशियल्स नहीं होते हैं।
• प्राधिकरण सर्वर के लिए सुरक्षित रूप से प्रमाणीकरण नहीं कर सकते हैं।
• Security Implication: एक हमलावर टोकन मांगते समय एक सार्वजनिक क्लाइंट एप्लिकेशन का अनुकरण कर सकता है, क्योंकि प्राधिकरण सर्वर के लिए एप्लिकेशन की वैधता की पुष्टि करने का कोई तंत्र नहीं है।

Authentication Tokens

OIDC में तीन प्रकार के टोकन होते हैं:

• Access Tokens: क्लाइंट इस टोकन को संसाधन सर्वर को संसाधनों तक पहुँचने के लिए प्रस्तुत करता है। इसे केवल उपयोगकर्ता, क्लाइंट और संसाधन के विशिष्ट संयोजन के लिए उपयोग किया जा सकता है और समाप्ति तक रद्द नहीं किया जा सकता - जो कि डिफ़ॉल्ट रूप से 1 घंटा है।
• ID Tokens: क्लाइंट को यह टोकन प्राधिकरण सर्वर से प्राप्त होता है। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है।
• Refresh Tokens: क्लाइंट को एक्सेस टोकन के साथ प्रदान किया जाता है। इसका उपयोग नए एक्सेस और ID टोकन प्राप्त करने के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। निष्क्रिय रिफ्रेश टोकनों के लिए डिफ़ॉल्ट समाप्ति 90 दिन है और सक्रिय टोकनों के लिए कोई समाप्ति नहीं है (एक रिफ्रेश टोकन से नए रिफ्रेश टोकन प्राप्त करना संभव है)।
• एक रिफ्रेश टोकन को एक aud , कुछ scopes, और एक tenant से जोड़ा जाना चाहिए और इसे केवल उस aud, scopes (और अधिक नहीं) और tenant के लिए एक्सेस टोकन उत्पन्न करने में सक्षम होना चाहिए। हालाँकि, यह FOCI एप्लिकेशन टोकन के साथ ऐसा नहीं है।
• एक रिफ्रेश टोकन एन्क्रिप्टेड होता है और केवल माइक्रोसॉफ्ट इसे डिक्रिप्ट कर सकता है।
• नया रिफ्रेश टोकन प्राप्त करने से पिछले रिफ्रेश टोकन को रद्द नहीं किया जाता है।

Access Tokens "aud"

"aud" फ़ील्ड में निर्दिष्ट फ़ील्ड वह resource server (एप्लिकेशन) है जिसका उपयोग लॉगिन करने के लिए किया जाता है।

कमांड az account get-access-token --resource-type [...] निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप एक्सेस टोकन में एक विशिष्ट "aud" जोड़ेगा:

Access Tokens Scopes "scp"

एक एक्सेस टोकन का स्कोप एक्सेस टोकन JWT के अंदर scp कुंजी के अंदर स्टोर किया जाता है। ये स्कोप परिभाषित करते हैं कि एक्सेस टोकन को किस चीज़ तक पहुँच प्राप्त है।

यदि एक JWT को किसी विशिष्ट API से संपर्क करने की अनुमति है लेकिन अनुरोधित क्रिया को करने के लिए स्कोप नहीं है, तो यह उस JWT के साथ क्रिया करने में असमर्थ होगा।

Get refresh & access token example

# Code example from https://github.com/secureworks/family-of-client-ids-research
import msal
import requests
import jwt
from pprint import pprint
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
)
device_flow = azure_cli_client.initiate_device_flow(
scopes=["https://graph.microsoft.com/.default"]
)
print(device_flow["message"])

# Perform device code flow authentication

azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
device_flow
)
pprint(azure_cli_bearer_tokens_for_graph_api)


# DECODE JWT
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
"""Decodes base64 encoded JWT blob"""
return jwt.decode(
base64_blob, options={"verify_signature": False, "verify_aud": False}
)
decoded_access_token = decode_jwt(
azure_cli_bearer_tokens_for_graph_api.get("access_token")
)
pprint(decoded_access_token)


# GET NEW ACCESS TOKEN AND REFRESH TOKEN
new_azure_cli_bearer_tokens_for_graph_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
# Same scopes as original authorization
scopes=["https://graph.microsoft.com/.default"],
)
)
pprint(new_azure_cli_bearer_tokens_for_graph_api)

अन्य एक्सेस टोकन फ़ील्ड

• 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 के समान मान), समाप्ति समय।

FOCI टोकन विशेषाधिकार वृद्धि

पहले उल्लेख किया गया था कि रिफ्रेश टोकन को उन स्कोप्स से जोड़ा जाना चाहिए जिनके साथ इसे उत्पन्न किया गया था, एप्लिकेशन और टेनेट से जिसे इसे उत्पन्न किया गया था। यदि इनमें से कोई भी सीमा टूटती है, तो विशेषाधिकार बढ़ाना संभव है क्योंकि अन्य संसाधनों और टेनेट के लिए एक्सेस टोकन उत्पन्न करना संभव होगा जिन तक उपयोगकर्ता की पहुंच है और जिनमें अधिक स्कोप हैं जितना कि मूल रूप से इरादा किया गया था।

इसके अलावा, यह सभी रिफ्रेश टोकन के साथ संभव है Microsoft identity platform (Microsoft Entra खाते, Microsoft व्यक्तिगत खाते, और Facebook और Google जैसे सामाजिक खाते) में क्योंकि दस्तावेज़ में उल्लेख किया गया है: "रिफ्रेश टोकन उपयोगकर्ता और क्लाइंट के संयोजन से बंधे होते हैं, लेकिन किसी संसाधन या टेनेट से बंधे नहीं होते। एक क्लाइंट रिफ्रेश टोकन का उपयोग करके एक्सेस टोकन प्राप्त कर सकता है किसी भी संसाधन और टेनेट के संयोजन में जहाँ इसे ऐसा करने की अनुमति है। रिफ्रेश टोकन एन्क्रिप्टेड होते हैं और केवल Microsoft identity platform इन्हें पढ़ सकता है।"

इसके अलावा, ध्यान दें कि FOCI एप्लिकेशन सार्वजनिक एप्लिकेशन हैं, इसलिए सर्वर पर प्रमाणित करने के लिए कोई सीक्रेट की आवश्यकता नहीं है।

फिर ज्ञात FOCI क्लाइंट्स मूल शोध में रिपोर्ट किए गए हैं यहाँ पाया जा सकता है।

विभिन्न स्कोप प्राप्त करें

पिछले उदाहरण कोड के साथ आगे बढ़ते हुए, इस कोड में एक अलग स्कोप के लिए एक नया टोकन अनुरोध किया गया है:

# Code from https://github.com/secureworks/family-of-client-ids-research
azure_cli_bearer_tokens_for_outlook_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
new_azure_cli_bearer_tokens_for_graph_api.get(
"refresh_token"
),
# But different scopes than original authorization
scopes=[
"https://outlook.office.com/.default"
],
)
)
pprint(azure_cli_bearer_tokens_for_outlook_api)

विभिन्न क्लाइंट और स्कोप प्राप्त करें

# Code from https://github.com/secureworks/family-of-client-ids-research
microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
microsoft_office_bearer_tokens_for_graph_api = (
# This is a different client application than we used in the previous examples
microsoft_office_client.acquire_token_by_refresh_token(
# But we can use the refresh token issued to our original client application
azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
# And request different scopes too
scopes=["https://graph.microsoft.com/.default"],
)
)
# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)

Where to find 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 अनुरोध का कैश है
• इसे लोड करें: 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 में लॉग इन है, तो इस पोस्ट के अनुसार, प्रमाणीकरण प्रवाह शुरू करना संभव है लोकलहोस्ट पर रीडायरेक्ट के साथ, ब्राउज़र को स्वचालित रूप से लॉगिन अधिकृत करने के लिए बनाना, और रिफ्रेश टोकन प्राप्त करना। ध्यान दें कि केवल कुछ FOCI एप्लिकेशन हैं जो लोकलहोस्ट पर रीडायरेक्ट की अनुमति देते हैं (जैसे az cli या पावरशेल मॉड्यूल), इसलिए इन एप्लिकेशनों को अनुमति दी जानी चाहिए।

References

• 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