إعداد تدفق بيانات اعتماد كلمة مرور مالك المورد في Azure Active Directory B2C
قبل أن تبدأ استخدم اختر نوع النهجالمحدد لاختيار نوع النهج التي تقوم بإعدادها. يوفر Azure Active Directory B2C طريقتين لتحديد كيفية تفاعل المستخدمين مع تطبيقاتك: من خلال تدفقات محددة مسبقا للمستخدمين أو من خلال سياسات مخصصة قابلة للتكوين بشكل كامل. تختلف الخطوات المطلوبة في هذه المقالة لكل أسلوب.
في Azure Active Directory B2C (Azure AD B2C)، تدفق بيانات اعتماد كلمة مرور مالك المورد (ROPC) هو تدفق مصادقة قياسية لـ OAuth. في هذا التدفق، يقوم أحد التطبيقات، المعروف أيضًا باسم جهة اعتماد، بتبادل بيانات اعتماد صالحة للرموز المميزة. تتضمن بيانات الاعتماد معرف المستخدم وكلمة المرور. الرموز المميزة التي تم إرجاعها هي رمز مميز للمعرف ورمز مميزة للوصول ورمز مميز للتحديث.
التحذير
نوصي بعدم استخدام تدفق ROPC. في معظم السيناريوهات، تتوفر بدائل أكثر أمانًا ويُنصح بها. يتطلب هذا التدفق درجة عالية جدا من الثقة في التطبيق ويحمل مخاطر غير موجودة في تدفقات أخرى. ينبغي ألّا تستخدم هذا التدفق إلا عندما لا يمكن استخدام تدفقات أخرى أكثر أمانًا.
ملاحظات تدفق ROPC
في Azure Active Directory B2C (Azure AD B2C)، يتم دعم الخيارات التالية:
- العميل الأصلي: يحدث تفاعل المستخدم أثناء المصادقة عند تشغيل التعليمات البرمجية على جهاز من جانب المستخدم. يمكن أن يكون الجهاز تطبيقًا للجوال يعمل في نظام تشغيل أصلي، مثل Android وiOS.
- تدفق عميل عام:يتم إرسال بيانات اعتماد المستخدم فقط، التي تم جمعها بواسطة أحد التطبيقات، في استدعاء واجهة برمجة التطبيقات للنظام. لا يتم إرسال بيانات اعتماد التطبيق.
- إضافة مطالبات جديدة: يمكن تغيير محتويات الرمز المميز للمعرف لإضافة مطالبات جديدة.
التدفقات التالية غير مدعومة:
- خادم إلى خادم: يحتاج نظام حماية الهوية إلى عنوان IP موثوق به تم جمعه من المتستدعي (العميل الأصلي) كجزء من التفاعل. في استدعاء واجهة برمجة التطبيقات للنظام من جانب الخادم، يتم استخدام عنوان IP الخاص بالخادم فقط. إذا تم تجاوز حد ديناميكي من المصادقة الفاشلة، قد يتعرف نظام حماية الهوية على عنوان IP المتكرر كمهاجم.
- تدفق العميل السري: يتم التحقق من صحة معرف عميل التطبيق، ولكن لم يتم التحقق من صحة سر التطبيق.
عند استخدام تدفق ROPC، خذ بعين الاعتبار ما يلي:
- لا يعمل ROPC عندما يكون هناك أي انقطاع في تدفق المصادقة الذي يحتاج إلى تفاعل المستخدم. على سبيل المثال، عند انتهاء مدة صلاحية كلمة مرور أو تحتاج إلى تغيير، تلزم المصادقة متعددة العوامل، أو عندما تحتاج إلى جمع المزيد من المعلومات أثناء تسجيل الدخول (على سبيل المثال، موافقة المستخدم).
- يدعم ROPC الحسابات المحلية فقط. لا يمكن للمستخدمين تسجيل الدخول باستخدام موفري خدمة هوية موحد مثل Microsoft أو Google+ أو Twitter أو AD-FS أو Facebook.
- إدارة الجلسة، بما في ذلك الاستمرار في تسجيل الدخول (KMSI) غير قابلة للتطبيق.
تسجيل تطبيق
لتسجيل تطبيق في مستأجر Azure AD B2C، يمكنك استخدام تجربة تسجيلات التطبيق الموحدة الجديدة أو تجربة تطبيقاتنا القديمة. تعرف على المزيد عن التجربة الجديدة.
- سجل الدخول إلى مدخل Azure.
- تأكد من استخدام الدليل الذي يحتوي على مستأجر Azure AD B2C:
- حدّد أيقونة الدلائل + الاشتراكات في شريط أدوات المدخل.
- في صفحة Portal settings | Directories + subscriptions ابحث عن دليل Azure AD B2C في قائمة Directory name ثم حدّد Switch.
- في مدخل Azure، ابحث عن Azure AD B2Cوحدده
- حدد App registrations، ثم حدد New registration.
- أدخل Name للتطبيق. على سبيل المثال، ROPC_Auth_app.
- اترك القيم الأخرى كما هي، ثم حدد تسجيل.
- تسجيل معرف التطبيق (العميل) للاستخدام في خطوة لاحقة.
- ضمن "Manage"، حدد "Authentication".
- حدد تجربة التجربة الجديدة (إذا تم عرضها).
- ضمن إعدادات متقدمة، والقسم تمكين تدفقات سطح المكتب والأجهزة المحمولة التالية، حدد نعم للتعامل مع التطبيق كعميل عام. هذا الإعداد مطلوب لتدفق ROPC.
- حدد حفظ.
- في القائمة اليسرى، حدد بيان التطبيق لفتح محرر بيان التطبيق.
- تعيين السمة oauth2AllowImplicitFlow إلى true:
"oauth2AllowImplicitFlow": true,
- حدد حفظ.
إنشاء تدفق مستخدم مالك مورد
- سجّل الدخول إلى مدخل Azure بصفتك المسؤول العام عن مستأجر Azure AD B2C.
- إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
- في مدخل Microsoft Azure، ابحث عن Azure AD B2C وحددها.
- حدِّد User flows، وحدِّد New user flow.
- حدد Sign in using resource owner password credentials (ROPC).
- ضمن Version، تأكد من تحديد Preview ثم حدد Create.
- توفير اسم لتدفق المستخدم، مثل ROPC_Auth.
- ضمن مطالبات الطلبات ، حدد إظهار المزيد .
- حدد مطالبات التطبيق التي تحتاجها للتطبيق الخاص بك، مثل الاسم المعروض وعنوان البريد الإلكتروني ومزود الهوية.
- حدد OK، ثم حدد Create.
المتطلب الأساسي
إذا لم تقم بذلك، تعرف على حزمة بادئ النهج المخصصة في البدء باستخدام النهج المخصصة في Active Directory B2C.
إنشاء نهج مالك المورد
افتح الملف TrustFrameworkExtensions.xml.
إذا لم يكن موجودًا بالفعل، قم بإضافة عنصر ClaimsSchema وعناصره التابعة كعنصر أول ضمن عنصر BuildingBlocks:
<ClaimsSchema> <ClaimType Id="logonIdentifier"> <DisplayName>User name or email address that the user can use to sign in</DisplayName> <DataType>string</DataType> </ClaimType> <ClaimType Id="resource"> <DisplayName>The resource parameter passes to the ROPC endpoint</DisplayName> <DataType>string</DataType> </ClaimType> <ClaimType Id="refreshTokenIssuedOnDateTime"> <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName> <DataType>string</DataType> </ClaimType> <ClaimType Id="refreshTokensValidFromDateTime"> <DisplayName>An internal parameter used to determine whether the user should be permitted to authenticate again using their existing refresh token.</DisplayName> <DataType>string</DataType> </ClaimType> </ClaimsSchema>
بعد ClaimsSchema، أضف عنصر ClaimsTransformations وعناصره التابعة إلى عنصر BuildingBlocks:
<ClaimsTransformations> <ClaimsTransformation Id="CreateSubjectClaimFromObjectID" TransformationMethod="CreateStringClaim"> <InputParameters> <InputParameter Id="value" DataType="string" Value="Not supported currently. Use oid claim." /> </InputParameters> <OutputClaims> <OutputClaim ClaimTypeReferenceId="sub" TransformationClaimType="createdClaim" /> </OutputClaims> </ClaimsTransformation> <ClaimsTransformation Id="AssertRefreshTokenIssuedLaterThanValidFromDate" TransformationMethod="AssertDateTimeIsGreaterThan"> <InputClaims> <InputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" TransformationClaimType="leftOperand" /> <InputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" TransformationClaimType="rightOperand" /> </InputClaims> <InputParameters> <InputParameter Id="AssertIfEqualTo" DataType="boolean" Value="false" /> <InputParameter Id="AssertIfRightOperandIsNotPresent" DataType="boolean" Value="true" /> </InputParameters> </ClaimsTransformation> </ClaimsTransformations>
قم بتحديد موقع عنصر ClaimsProvider يحتوي على DisplayName
Local Account SignIn
وأضف التشكيل الجانبي التقني التالي:<TechnicalProfile Id="ResourceOwnerPasswordCredentials-OAUTH2"> <DisplayName>Local Account SignIn</DisplayName> <Protocol Name="OpenIdConnect" /> <Metadata> <Item Key="UserMessageIfClaimsPrincipalDoesNotExist">We can't seem to find your account</Item> <Item Key="UserMessageIfInvalidPassword">Your password is incorrect</Item> <Item Key="UserMessageIfOldPasswordUsed">Looks like you used an old password</Item> <Item Key="DiscoverMetadataByTokenIssuer">true</Item> <Item Key="ValidTokenIssuerPrefixes">https://sts.windows.net/</Item> <Item Key="METADATA">https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration</Item> <Item Key="authorization_endpoint">https://login.microsoftonline.com/{tenant}/oauth2/token</Item> <Item Key="response_types">id_token</Item> <Item Key="response_mode">query</Item> <Item Key="scope">email openid</Item> <Item Key="grant_type">password</Item> </Metadata> <InputClaims> <InputClaim ClaimTypeReferenceId="logonIdentifier" PartnerClaimType="username" Required="true" DefaultValue="{OIDC:Username}"/> <InputClaim ClaimTypeReferenceId="password" Required="true" DefaultValue="{OIDC:Password}" /> <InputClaim ClaimTypeReferenceId="grant_type" DefaultValue="password" /> <InputClaim ClaimTypeReferenceId="scope" DefaultValue="openid" /> <InputClaim ClaimTypeReferenceId="nca" PartnerClaimType="nca" DefaultValue="1" /> <InputClaim ClaimTypeReferenceId="client_id" DefaultValue="ProxyIdentityExperienceFrameworkAppId" /> <InputClaim ClaimTypeReferenceId="resource_id" PartnerClaimType="resource" DefaultValue="IdentityExperienceFrameworkAppId" /> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="oid" /> <OutputClaim ClaimTypeReferenceId="userPrincipalName" PartnerClaimType="upn" /> </OutputClaims> <OutputClaimsTransformations> <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" /> </OutputClaimsTransformations> <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" /> </TechnicalProfile>
استبدال DefaultValueclient_id بمعرف التطبيق من تطبيق ProxyIdentityExperienceFramework الذي قمت بإنشائه في البرنامج التعليمي للمتطلبات الأساسية. ثم استبدال DefaultValue من resource_id بمعرف التطبيق من تطبيق IdentityExperienceFramework الذي قمت بإنشائه أيضاً في البرنامج التعليمي للمتطلبات الأساسية.
إضافة عناصر ClaimsProvider التالية مع التشكيلات الجانبية التقنية الخاصة بهم إلى عنصر ClaimsProviders:
<ClaimsProvider> <DisplayName>Azure Active Directory</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="AAD-UserReadUsingObjectId-CheckRefreshTokenDate"> <Metadata> <Item Key="Operation">Read</Item> <Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item> </Metadata> <InputClaims> <InputClaim ClaimTypeReferenceId="objectId" Required="true" /> </InputClaims> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="refreshTokensValidFromDateTime" /> </OutputClaims> <OutputClaimsTransformations> <OutputClaimsTransformation ReferenceId="AssertRefreshTokenIssuedLaterThanValidFromDate" /> <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromObjectID" /> </OutputClaimsTransformations> <IncludeTechnicalProfile ReferenceId="AAD-Common" /> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider> <ClaimsProvider> <DisplayName>Session Management</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="SM-RefreshTokenReadAndSetup"> <DisplayName>Trustframework Policy Engine Refresh Token Setup Technical Profile</DisplayName> <Protocol Name="None" /> <OutputClaims> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="refreshTokenIssuedOnDateTime" /> </OutputClaims> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider> <ClaimsProvider> <DisplayName>Token Issuer</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="JwtIssuer"> <Metadata> <!-- Point to the redeem refresh token user journey--> <Item Key="RefreshTokenUserJourneyId">ResourceOwnerPasswordCredentials-RedeemRefreshToken</Item> </Metadata> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>
إضافة عنصر UserJourneys والعناصر التابعة إلى عنصر TrustFrameworkPolicy:
<UserJourney Id="ResourceOwnerPasswordCredentials"> <PreserveOriginalAssertion>false</PreserveOriginalAssertion> <OrchestrationSteps> <OrchestrationStep Order="1" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="ResourceOwnerFlow" TechnicalProfileReferenceId="ResourceOwnerPasswordCredentials-OAUTH2" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="2" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="AADUserReadWithObjectId" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> </OrchestrationSteps> </UserJourney> <UserJourney Id="ResourceOwnerPasswordCredentials-RedeemRefreshToken"> <PreserveOriginalAssertion>false</PreserveOriginalAssertion> <OrchestrationSteps> <OrchestrationStep Order="1" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="RefreshTokenSetupExchange" TechnicalProfileReferenceId="SM-RefreshTokenReadAndSetup" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="2" Type="ClaimsExchange"> <ClaimsExchanges> <ClaimsExchange Id="CheckRefreshTokenDateFromAadExchange" TechnicalProfileReferenceId="AAD-UserReadUsingObjectId-CheckRefreshTokenDate" /> </ClaimsExchanges> </OrchestrationStep> <OrchestrationStep Order="3" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" /> </OrchestrationSteps> </UserJourney>
في صفحة Custom Policies في مستأجر Azure AD B2C، حدد Upload Policy.
تمكين الكتابة فوق النهج إذا كان موجوداً،ثم استعرض ملف TrustframeworkExtensions.xml وحدده.
حدد تحميل.
إنشاء ملف جهة اعتماد
بعد ذلك، قم بتحديث ملف جهة الاعتماد الذي يبدأ رحلة المستخدم التي قمت بإنشائها:
قم بعمل نسخة من ملف SignUpOrSignin.xml في دليل العمل الخاص بك ثم أعد تسميته إلى ROPC_Auth.xml.
افتح الملف الجديد وقم بتغيير قيمة سمة PolicyId لـ TrustFrameworkPolicy إلى قيمة فريدة. معرف السياسة هو اسم النهج الخاص بك. على سبيل المثال، B2C_1A_ROPC_Auth.
تغيير قيمة السمة ReferenceId في DefaultUserJourney إلى
ResourceOwnerPasswordCredentials
.تغيير عنصر OutputClaims لاحتواء المطالبات التالية فقط:
<OutputClaim ClaimTypeReferenceId="sub" /> <OutputClaim ClaimTypeReferenceId="objectId" /> <OutputClaim ClaimTypeReferenceId="displayName" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="givenName" DefaultValue="" /> <OutputClaim ClaimTypeReferenceId="surname" DefaultValue="" />
في صفحة Custom Policies في مستأجر Azure AD B2C، حدد Upload Policy.
تمكين الكتابة فوق النهج إذا كان موجوداً،ثم استعرض ملف ROPC_Auth.xml وحدده.
حدد تحميل.
اختبار تدفق ROPC
استخدم تطبيق تطوير واجهة برمجة التطبيقات المفضل لديك لإنشاء استدعاء واجهة برمجة التطبيقات، ومراجعة الاستجابة لتصحيح النهج الخاص بك. إنشاء استدعاء مثل هذا المثال مع المعلومات التالية مثل نص طلب POST:
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token
- استبدل
<tenant-name>
باسم مستأجر متاجرة عمل-مستهلك Azure AD. - استبدال
B2C_1A_ROPC_Auth
بالاسم الكامل لنهج بيانات اعتماد كلمة المرور لمالك المورد.
مفتاح | القيمة |
---|---|
اسم المستخدم | user-account |
كلمة المرور | password1 |
grant_type | كلمة المرور |
النطاق | openid application-id offline_access |
client_id | application-id |
response_type | token id_token |
- استبدل
user-account
باسم حساب مستخدم في المستأجر. - استبدال
password1
بكلمة المرور لحساب المستخدم. - استبدال
application-id
بمعرف الطلب من تسجيل ROPC_Auth_app. - Offline_access اختياري إذا كنت ترغب في تلقي رمز مميز للتحديث.
يبدو طلب POST الفعلي مثل المثال التالي:
POST /<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded
username=contosouser.outlook.com.ws&password=Passxword1&grant_type=password&scope=openid+bef22d56-552f-4a5b-b90a-1988a7d634ce+offline_access&client_id=bef22d56-552f-4a5b-b90a-1988a7d634ce&response_type=token+id_token
تبدو استجابة ناجحة مع وصول دون اتصال كالمثال التالي:
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki...",
"token_type": "Bearer",
"expires_in": "3600",
"refresh_token": "eyJraWQiOiJacW9pQlp2TW5pYVc2MUY0TnlfR3REVk1EVFBLbUJLb0FUcWQ1ZWFja1hBIiwidmVyIjoiMS4wIiwiemlwIjoiRGVmbGF0ZSIsInNlciI6Ij...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ik9YQjNhdTNScWhUQWN6R0RWZDM5djNpTmlyTWhqN2wxMjIySnh6TmgwRlki..."
}
قبول رمز مميز للتحديث
إنشاء استدعاء POST مثل ذلك المعروض هنا. استخدم المعلومات الموجودة في الجدول التالي كنص الطلب:
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/B2C_1A_ROPC_Auth/oauth2/v2.0/token
- استبدل
<tenant-name>
باسم مستأجر متاجرة عمل-مستهلك Azure AD. - استبدال
B2C_1A_ROPC_Auth
بالاسم الكامل لنهج بيانات اعتماد كلمة المرور لمالك المورد.
مفتاح | القيمة |
---|---|
grant_type | refresh_token |
response_type | id_token |
client_id | application-id |
resource | application-id |
refresh_token | refresh-token |
- استبدال
application-id
بمعرف الطلب من تسجيل ROPC_Auth_app. - استبدال
refresh-token
بـ refresh_token الذي تم إرساله مرة أخرى في الاستجابة السابقة.
تبدو الاستجابة الناجحة كالمثال التالي:
{
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQndhT...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrNHh5b2pORnVtMWtsMll0djhkbE5QNC1jNTdkTzZRR1RWQn...",
"token_type": "Bearer",
"not_before": 1533672990,
"expires_in": 3600,
"expires_on": 1533676590,
"resource": "bef2222d56-552f-4a5b-b90a-1988a7d634c3",
"id_token_expires_in": 3600,
"profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiI1MTZmYzA2NS1mZjM2LTRiOTMtYWE1YS1kNmVlZGE3Y2JhYzgiLCJzdWIiOm51bGwsIm5hbWUiOiJEYXZpZE11IiwicHJlZmVycmVkX3VzZXJuYW1lIjpudWxsLCJpZHAiOiJMb2NhbEFjY291bnQifQ",
"refresh_token": "eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMCIsInppcCI6IkRlZmxhdGUiLCJzZXIiOiIxLjAi...",
"refresh_token_expires_in": 1209600
}
استكشاف الأخطاء وإصلاحها
لم يتم تكوين التطبيق المقدم للسماح بالتدفق الضمني "OAuth"
- العرض - يمكنك تشغيل تدفق ROPC، والحصول على الرسالة التالية: AAD (دليل Azure النشط)B2C90057: لم يتم تكوين التطبيق المقدم للسماح بالتدفق الضمني "OAuth".
- الأسباب المحتملة - لا يسمح بالتدفق الضمني للتطبيق الخاص بك.
- الحل: عند إنشاء تسجيل التطبيق الخاص بك في Azure AD B2C، تحتاج إلى تحرير بيان التطبيق يدويا وتعيين قيمة الخاصية
oauth2AllowImplicitFlow
إلىtrue
. بعد تكوين الخاصيةoauth2AllowImplicitFlow
، قد يستغرق الأمر بضع دقائق (عادة لا يزيد عن خمسة) حتى يتفاعل التغيير.
استخدام SDK أصلي أو App-Auth
يتوافق Azure AD B2C مع معايير OAuth 2.0 لبيانات اعتماد كلمة مرور مالك مورد العميل العام ويجب أن يكون متوافقًا مع معظم SDK العميل. للحصول على أحدث المعلومات، راجع SDK للتطبيق الأصلي لـ OAuth 2.0 وOpenID Connect لتطبيق أفضل الممارسات الحديثة.
الخطوات التالية
تنزيل عينات العمل التي تم تكوينها للاستخدام مع Azure AD B2C من GitHub، لـ Android ولـ iOS.