## مقدمة [Logto](https://logto.io/) توفر للمطورين لدينا والمجموعات التجارية حلاً شاملاً لإدارة هوية العميل والوصول (CIAM). نحن نوفر مجموعة واسعة من SDKs الجاهزة للاستخدام للمنصات والأطر التطبيقية المختلفة. مع خدمة السحابة Logto، يمكنك بسهولة إنشاء تدفق تفويض المستخدم الآمن للغاية لتطبيقك في غضون دقائق. كشركة ولدت من مجتمع المطورين، ي embrace Logto وتقدر تفاعل مجتمعنا. بالإضافة إلى SDKs Logto التي تم تطويرها رسمياً، نشجع ونرحب بحرارة بالمطورين من المجتمع للمساهمة بخبراتهم من خلال إنشاء المزيد من SDKs المتعددة وسهلة الاستخدام، والتي تلبي الاحتياجات الفريدة للمنصات والأطر المختلفة. في هذه المقالة، سوف نوضح باختصار كيفية تنفيذ SDK مصدق قياسي لـ OIDC خطوة بخطوة. أنشئ تطبيقك في Logto ## السياق تدفق OpenID Connect (OIDC) هو بروتوكول مصدق يبنى على إطار OAuth 2.0 لتوفير التحقق من الهوية وقدرات تسجيل الدخول الفردي. يسمح للمستخدمين بالتحقق من هويتهم مع تطبيق والحصول على تفويض للوصول إلى أي موارد خاصة بشكل آمن. يرجى الرجوع إلى مواصفات OIDC لمزيد من التفاصيل. ### سير العمل يتضمن تدفق رمز التفويض القياسي الخطوات التالية: ```mermaid sequenceDiagram actor user as End User participant app as Client App participant server as Authorization Server participant resource as Private Resources user ->> app: anonymous visitor sign-in app ->> server: send authentication request server -->> user: redirect to the user sign-in page user ->> server: sign-in with credentials server -->> app: redirect back to the client app with authorization_code app ->> server: token exchange request with the authorization_code server ->> app: grant id_token, access_token and refresh_token app -->> user: authenticated app ->> resource: private api request with access_token resource --> server: sync signing key resource -->> resource: token validation resource ->> app: 200 OK ``` #### تدفق المصادقة 1. **المستخدم يشرع في طلب الدخول:** يأتي مستخدم مجهول إلى تطبيقك من مدخل عام. يحاول الحصول على المصادقة وربما يطلب في وقت لاحق الوصول إلى مورد محمي في تطبيق أو خدمة طرف ثالث. 2. **مصادقة المستخدم:** ينشئ تطبيق العميل رابط مصادقة ويرسل طلباً إلى خادم التفويض، الذي يقوم بإعادة توجيه المستخدم إلى صفحة تسجيل الدخول الخاصة به. يتفاعل المستخدم مع صفحة تسجيل الدخول باستخدام مجموعة واسعة من طرق الدخول ويتم التحقق من هويته بواسطة خادم التفويض. 3. **التعامل مع إرجاع تسجيل الدخول:** عند المصادقة الناجحة، سيتم إعادة توجيه المستخدم إلى تطبيقك برمز `authorization_code` الممنوح. يحتوي هذا `authorization_code` على جميع الأذونات ذات الصلة المرتبطة بحالة المصادقة وبيانات التفويض المطلوبة. 4. **تبادل الرموز:** طلب لتبادل الرموز باستخدام `authorization_code` المستخرج من عنوان الإعادة أعلاه. في المقابل: - `id_token`: JWT موقعة رقمياً تحتوي على معلومات الهوية عن المستخدم المصدق. - `access_token`: `access_token` معتم غير شفاف يمكن استخدامه للوصول إلى نهاية معلومات المستخدم الأساسية. - `refresh_token`: رمز اعتماد يسمح للمستخدم بإجراء تبادل مستمر للحصول على `access_token` #### تدفق التفويض 1. **الوصول إلى معلومات المستخدم:** للوصول إلى مزيد من معلومات المستخدم، يمكن للتطبيق إجراء طلبات إضافية إلى نقطة النهاية UserInfo، باستخدام `access_token` غير الشفاف الذي تم الحصول عليه من تدفق تبادل الرموز الأولي. وهذا يمكّن من استرداد تفاصيل إضافية عن المستخدم، مثل عنوان بريده الإلكتروني أو صورة ملفه الشخصي. 2. **منح الوصول إلى المورد المحمي:** إذا لزم الأمر، يمكن للتطبيق إجراء طلبات إضافية إلى نقطة النهاية الخاصة بتبادل الرموز، باستخدام `refresh_token` مجتمعة مع `resource` و `scope` للحصول على `access_token` مخصص للمستخدم للوصول إلى المورد المستهدف. ينتج عن هذه العملية إصدار `access_token` مُشكّل بتنسيق JWT يحتوي على جميع المعلومات اللازمة للتفويض للوصول إلى المورد المحمي. ## التنفيذ سنتبع بعض استراتيجيات التصميم داخل SDK نمط الجافا سكريبت @logto/client لتوضيح عملية تنفيذ SDK بسيطة لتطبيق عميلك الخاص. يرجى ملاحظة أن بنية الكود التفصيلية قد تختلف تبعاً للإطار الزمني للعميل الذي تعمل معه. لا تتردد في اختيار أي من SDKs Logto الرسمية كمثال لمشروع SDK الخاص بك. ### معاينة ```ts class LogtoClient { protected readonly logtoConfig: LogtoConfig; protected readonly storage: Storage; protected oidcConfig: OidcConfig; protected accessTokenMap: Map constructor(logtoConfig: LogtoConfig) {} get async idToken(){} private async getOidcConfig(){} private async getJwksFunction() {} private async verifyIdToken() {} private async saveTokens() {} private async setSignInSession() {} private async getSignInSession() {} private async getAccessTokenByRefreshToken() {} async signIn(redirectUri: string) {} async handlerSignInCallback (callbackUri: string) {} async getUserInfo() {} async getAccessToken(resource?: string, scopes?: string[]) {} } ``` ### المُنشئ يجب أن يأخذ المُنشئ [logtoConfig](#logto-config) كمدخل. هذا يوفر جميع التكوينات الضرورية التي ستحتاج إليها لإقامة اتصال مصادق من خلاله هذا SDK. اعتمادًا على المنصة أو الإطار الذي تستخدمه لـ SDK، يمكنك تمرير مثيل تخزين محلي مستدام للمُنشئ. سيتم استخدام مثيل التخزين هذا لتخزين جميع الرموز والأسرار المتعلقة بالتفويض. ```ts class LogtoClient { constructor(logtoConfig: LogtoConfig, storage: Storage) {} } ``` ### تهيئة مصادقة المستخدم قبل إنشاء رابط طلب المصادقة، من الضروري إكمال عدة خطوات تجهيز لضمان عملية آمنة. #### الحصول على تكوينات OIDC من خادم التفويض حدد طريقة خاصة `getOidcConfigs` لجلب تكوينات OIDC من نقطة اكتشاف خادم التفويض. استجابة تكوينات OIDC تحتوي على جميع المعلومات الوصفية التي يمكن للعميل استخدامها للتفاعل مع خادم التفويض، بما في ذلك مواقع نقاط النهاية وقدرات الخادم. (يرجى الرجوع إلى [مواصفات ميتاداتا الخادم OAuth OAuth](https://datatracker.ietf.org/doc/html/rfc8414) لمزيد من التفاصيل.) ```ts const discoveryPath = "/oidc/.well-known/openid-configuration"; private async getOidcConfigs() { if (this.oidcConfig) { return this.oidcConfig; } const response = await fetch(`${this.logtoConfig.endpoint}${discoveryPath}`) this.oidcConfig = await response.json(); return this.oidcConfig; } ``` #### مولد PKCE تدفق تحقق [PKCE(Proof Key for Code Exchange)](https://datatracker.ietf.org/doc/html/rfc7636) ضروري لجميع تدفقات تبادل رمز العميل العام. وهو يخفف من خطر اعتراض رمز التفويض. لذلك، هناك حاجة إلى `code_challenge` و `code_verifier` لجميع طلبات تفويض التطبيق العامة (مثل التطبيق الأصلي و SPA). طرق التنفيذ قد تختلف اعتمادًا على اللغات والأطر التي تستخدمها. يرجى الرجوع إلى [code_challenge](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) و [code_verifier](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) للتعريفات المفصلة. إذا كنت تعمل على عميل سري أو تطبيقات ويب تم تقديمها بواسطة الخادم مثل express أو nextjs، انتقل مباشرة إلى الخطوة التالية. لمزيد من المعلومات حول PKCE والفرق بين العملاء العموميين والعملاء السريين، يرجى مراجعة [مراجعة أمان OAuth](https://blog.logto.io/oauth-security-recap). ```ts class PKCE { readonly codeVerifier: String; readonly codeChallenge: String; constructor() { this.codeVerifier = this.generateCodeVerifier(); this.codeChallenge = this.generateCodeChallenge(this.codeVerifier); } /** * توليد رمز التحقق * * @link [العميل ينشئ رمز التحقق](https://datatracker.ietf.org/doc/html/rfc7636#section-4.1) */ private generateCodeVerifier() { return generateRandomString(); } /** * حساب S256 PKCE رمز التحدي لرمز تحقق عشوائي وترميزه بقاعدة64 آمنة للعنوان * * @param {String} codeVerifier كود التحقق الذي يجب حساب S256 رمز التحدي له * @link [العميل ينشئ رمز التحدي](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) */ private async generateCodeChallenge(codeVerifier: string) { const encodedCodeVerifier = new TextEncoder().encode(codeVerifier); const codeChallenge = new Uint8Array( await crypto.subtle.digest('SHA-256', encodedCodeVerifier) ); } } ``` #### إنشاء معامل الحالة في تدفق التفويض، يعد [معامل الحالة](https://blog.logto.io/oauth-security-recap/#state) قيمة يتم توليدها عشوائيًا ويتم تضمينها في طلب التفويض الذي يرسله العميل. ويعمل كإجراء أمني لمنع هجمات تزوير الطلبات بين المواقع (CSRF). ```ts const state = generateRandomString(); ``` #### تخزين معلومات الجلسة الوسيطة هناك عدة عوامل تحتاج إلى الاحتفاظ بها في التخزين لأغراض التحقق بعد أن يحصل المستخدم على المصادقة ويعاد توجيهه إلى الجانب العميل. نحن بصدد تنفيذ طريقة لتعيين هذه العوامل الوسيطة إلى التخزين. ```ts protected async setSignInSession (data: { codeVerifier: string; redirectUri: string; state: string; }) { await this.storage.setItem('signInSession', data); } ``` #### تسجيل الدخول دعونا نلخص كل ما تم تنفيذه أعلاه، حدد طريقة توليد عنوان URL لدخول المستخدم وإعادة توجيه المستخدم إلى خادم التفويض للحصول على المصادقة. ```ts async signIn(redirectUri: string) { const { appId, resources, scopes } = this.logtoConfig; const { authorizationEndpoint } = await this.getOidcConfig(); // لتطبيقات العملاء العامة فقط const pkce = new PKCE(); const state = generateRandomString(); const queryParameters = new URLSearchParams({ client_id: appId, redirect_uri: redirectUri, code_challenge: pkce.codeChallenge, code_challenge_method: 'S256', state, response_type: 'code', prompt: 'consent', scopes: [...reservedScopes, scopes], }); // إضافة جميع مؤشرات الموارد إن وجدت for (const resource of resources ?? []) { urlSearchParameters.append('resource', resource); } const signInUrl = new URL(`${authorizationEndpoint}?${urlSearchParameters.toString()}`); await this.setSignInSession({ redirectUri, state, codeVerifier: pkce.codeVerifier }); navigate(signInUrl); } ``` ### التعامل مع إرجاع تسجيل الدخول في القسم السابق، أنشأنا طريقة تسجيل دخول تنشئ عنوان URL لمصادقة المستخدم. يحتوي عنوان URL هذا على جميع المعلمات اللازمة لبدء تدفق المصادقة من تطبيق العميل. تقوم الطريقة بتوجيه المستخدم إلى صفحة تسجيل الدخول الخاصة بخادم التفويض للمصادقة. بعد تسجيل الدخول بنجاح، سيتم إعادة توجيه المستخدم النهائي إلى موقع `redirect_uri` المقدم أعلاه. سيتم حمل جميع المعلمات اللازمة في `redirect_uri` لإكمال تدفقات تبادل الرموز التالية. #### استخراج والتحقق من صحة عنوان URL للإرجاع هذه الخطوة من التحقق ضرورية للغاية لمنع أي أشكال من الهجمات التي تستخدم استدعاء تفويض مزيف. **يجب** التحقق بعناية من عنوان URL للمصادقة قبل إرسال طلب تبادل الرمز إلى خادم التفويض. أولاً، نحتاج إلى استعادة بيانات جلسة تسجيل الدخول التي قمنا بتخزينها من تخزين التطبيق. ```ts protected async getSignInSession () { session = await this.storage.getItem('signInSession', data); if (!session) { throw Error('Session not found'); } } ``` ثم التحقق من معلمات عنوان URL للإرجاع قبل إرسال طلب تبادل الرمز. - استخدام `redirectUri` المحفوظة مسبقًا للتحقق مما إذا كانت `callbackUri` هي نفسها التي أرسلناها إلى خادم التفويض. - استخدام `state` المحفوظة مسبقًا للتحقق مما إذا كانت الدولة المعادة هي نفسها التي أرسلناها إلى خادم التفويض. - تحقق مما إذا كان هناك خطأ يتم إعادته بواسطة خادم التفويض - تحقق من وجود `authorization_code` المرتجع ```ts verifyAndParseCodeFromCallbackUri(callbackUri: string, redirectUri: string, state: string) { const url = new URL(callbackUri) const parameters = url.searchParams; if (!callbackUri.startWith(redirectUri)) { throw new Error('redirect_uri_mismatched') } // تحقق من رسالة الخطأ. // إذا فشلت المصادقة، سيتم إعادة توجيه المستخدم بالعودة مع معلمات الخطأ المرفقة const error = parameters.get('error'); const errorDescription = parameters.get('error_description'); if (error || errorDescription) { throw new Error(`${error}:${errorDescription}`) } // التحقق من الدولة const callbackState = parameter.get('state'); if (callbackState !== state) { throw new Error('state_mismatch'); } // استخراج رمز التفويض const code = parameters.get('code'); if (!code) { throw new Error('authorization_code_not_found') } return code; } ``` #### إرسال طلب تبادل الرمز كخطوة نهائية لتدفق مصادقة المستخدم، سنستخدم `authorization_code` المرتجع لإرسال طلب تبادل الرمز والحصول على الرموز اللازمة للتفويض. لمزيد من التفاصيل حول تعريفات معلمات الطلب، يرجى الرجوع إلى [مواصفات تبادل الرمز](https://datatracker.ietf.org/doc/html/rfc8693#section-2). - code: `authorization_code` الذي تلقيناه من `callbackUri` - clientId: معرف التطبيق - redirectUri: نفس القيمة المستخدمة عند إنشاء عنوان URL لتسجيل الدخول للمستخدم. - codeVerifier: محقق كود PKCE. مثل `redirectUri`، سيقارن خادم التفويض هذه القيمة بما سبق أن أرسلناه، مما يضمن صحة طلب تبادل الرمز القادم. ```ts const getTokenByAuthorizationCode = async (payload: { code: string; clientId: string; tokenEndpoint: string; redirectUri: string; codeVerifier: string; }) => { const parameters = new URLSearchParams({ client_id: payload.clientId, code: payload.code, code_verifier: payload.codeVerifier, redirect_uri: payload.redirectUri, grant_type: 'authorization_code', }); return fetch(tokenEndpoint, { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded' } body: parameters, }); } ``` #### التعامل مع إرجاع تسجيل الدخول لنلخص كل ما لدينا. دعونا نبني طريقة التعامل مع إرجاع تسجيل الدخول (signInCallback): ```ts private async saveTokens({refreshToken, idToken, accessToken}) { this.storage.setItem('refreshToken', refreshToken); this.storage.setItem('idToken', idToken); // access token معتم بدون تحديد مؤشر الموارد this.accessTokenMap.setItem('', accessToken) } async handleSignInCallback(callbackUri: string){ const signInSession = await this.getSignInSession(); if (!signInSession) { throw new Error('sign_in_session.not_found'); } const { redirectUri, state, codeVerifier } = signInSession; const code = verifyAndParseCodeFromCallbackUri(callbackUri, redirectUri, state); const { appId } = this.logtoConfig; const { tokenEndpoint } = await this.getOidcConfig(); const response = await getTokenByAuthorizationCode({ code, clientId: appId, tokenEndpoint, redirectUri, codeVerifier, }); await this.saveTokens(response); } ``` وبذلك، ستعيد طلب تبادل الرمز الرموز التالية: - `id_token`: idToken OIDC، JSON Web Token (JWT) تحتوي على معلومات الهوية حول المستخدم المصدق. id_token يمكن أن تستخدم أيضًا كمصدر الحقائق الوحيد لحالة مصادقة المستخدم. - `access_token`: رمز التفويض الافتراضي الذي يعيده خادم التفويض. يمكن استخدامه لاستدعاء نقطة النهاية معلومات المستخدم وإسترجاع معلومات المستخدم المصدق. - `refresh_token`: (إذا كان نطاق offline_access موجود في طلب التفويض): يتيح هذا الرمز ال refresh للتطبيق العميل الحصول على رمز وصول جديد دون الحاجة إلى إعادة مصادقة المستخدم، مما يمنح الوصول طويل الأجل إلى الموارد. - `expires_in`: مدة الوقت، بالثواني، التي يكون فيها رمز الوصول صالحًا قبل انتهاء صلاحيته. ### تحقق من رمز المعرف (ID token) يعد التحقق واستخراج المطالبات من `id_token` خطوة حاسمة في عملية المصادقة لضمان أصالة وشمولية الرمز. فيما يلي الخطوات الرئيسية المشاركة في التحقق من `idToken`. - التحقق من التوقيع: يتم توقيع `id_token` رقميًا بواسطة خادم التفويض باستخدام مفتاحه الخاص. يحتاج تطبيق العميل إلى التحقق من التوقيع باستخدام المفتاح العام لخادم التفويض. هذا يضمن أن الرمز لم يتم العبث به وأنه تم إصداره فعلًا بواسطة خادم التفويض الشرعي. - تحقق المصدر (المصدر): تحقق من أن المطالبة "iss" (المصدر) في `id_token` تتطابق مع القيمة المتوقعة، مما يشير إلى أن الرمز أصدره خادم التفويض الصحيح. - التحقق من الجمهور: ضمان أن "aud" (الجمهور) المطالب بها في `id_token` تطابق معرف العميل لتطبيق العميل، مما يضمن أن الرمز موجه لجمهور العميل - التحقق من انتهاء الصلاحية: التحقق من أن المطالبة "iat" (وقتها) في `id_token` لم تتجاوز الوقت الحالي، مما يضمن أن الرمز لا يزال صالحًا. نظرًا لتكاليف المعاملة الشبكية، نحتاج إلى تعيين تحمل وقت إصدار عند التحقق من صحة المطالبة iat المرسلة يتم إرجاع `id_token` كـ JSON Web Token (JWT) قياسي. بناءً على الإطار الذي تستخدمه، يمكن أن تجد مجموعة متنوعة من المكونات الإضافية تحقق من صحة JWT لتساعد في فك تشفير والتحقق من الرمز. في هذا المثال، سنستخدم [jose](https://www.npmjs.com/package/jose) في SDK الجافا سكريبت الخاص بنا لتسهيل التحقق من الرمز وفك تشفيره. ```sh npm install jose ``` ```ts import {createRemoteJWKSet, jwtVerify} from 'jose'; private async getJwksFunction() { const { jwksUri } = await this.getOidcConfig(); return createRemoteJWKSet(new URL(jwksUri))(); } private async verifyIdToken( idToken: string, clientId: string, issuer: string, ) { const jwks = await this.getJwksFunction(); const result = await jwtVerify(idToken, jwks, { audience: clientId, issuer }); if (Math.abs((result.payload.iat ?? 0) - Date.now() / 1000) > issuedAtTimeTolerance) { throw new Error('id_token.invalid_iat'); } return result; }; ``` ### الحصول على معلومات المستخدم بعد نجاح مصادقة المستخدم، يمكن استرداد معلومات المستخدم الأساسية من `id_token` الصادر عن خادم التفويض OIDC. ومع ذلك، بسبب اعتبارات الأداء، يتم تقليل محتوى الرمز JWT. للحصول على معلومات أكثر تفصيلًا عن ملف تعريف المستخدم، توفر خوادم التخويل الممتثلة لـ OIDC نقطة نهاية لمعلومات المستخدم (userinfo) جاهزة للاستخدام. تتيح لك هذه النقطة المستهدفة استرداد بيانات ملف تعريف المستخدم الإضافية عن طريق طلب نطاقات ملف تعريف المستخدم المحددة. عند استدعاء نقطة تبادل الرمز بدون تحديد مورد واجهة برمجة التطبيقات الخاص، سيصدر خادم التفويض، بشكل افتراضي، `access_token` نوع معتم. يمكن استخدام هذا `access_token` فقط للوصول إلى نقطة نهاية معلومات المستخدم، مما يسمح باسترداد بيانات ملف تعريف المستخدم الأساسية. ```ts async getUserInfo() { const { userinfoEndpoint } = await this.getOidcConfig(); const accessToken = await this.getAccessToken(); return fetch(userinfoEndpoint, { headers: { Authorization: `Bearer ${accessToken}` } }); } ``` ### الحصول على access token لتفويض المورد المحمي في معظم الحالات، لا يحتاج تطبيق العميل إلى مصادقة المستخدم فحسب، بل يحتاج أيضًا إلى تفويض الوصول إلى موارد معينة محمية أو نقاط نهاية API. هنا، سنستخدم `refresh_token` الذي تم الحصول عليه أثناء تسجيل الدخول للحصول على `access_token(s)` المحدد الممنوح لإدارة موارد معينة. يُتيح لنا ذلك الحصول على الوصول إلى تلك APIs المحمية. خلال تسجيل دخول المستخدم، من المهم توفير جميع مؤشرات موارد واجهة برمجة التطبيقات إلى خادم التخويل. بعد نجاح المصادقة، يمكننا فقط استرجاع `access_tokens` للموارد المحددة التي تم تكوينها مسبقًا. لتحقيق ذلك، قم بتكوين جميع مؤشرات موارد واجهة برمجة التطبيقات المطلوبة في إعدادات تكوين تطبيق العميل قبل إنشاء عنوان URL لتسجيل الدخول. ```ts private async getAccessTokenByRefreshToken(resource?:string, scopes?: string[]){ const { appId } = this.logtoConfig; const { tokenEndpoint } = await this.getOidcConfig(); const { refreshToken } = await this.storage.getItem('refreshToken'); const parameters = new URLSearchParams({ 'grant_type': 'refresh_token', 'client_id': appId, 'refresh_token': }); if (resource) { parameters.append('resource', resource); } if (scopes?.length) { parameters.append('scope', scopes.join(' ')); } const response = await fetch(tokenEndpoint, { method: 'POST', grant_type: 'authorization_code', body: parameters, }); // احفظ واستبدل refreshToken الأخيرة التي تم إرجاعها await this.storage.setItem('refreshToken', response.refreshToken); await this.accessTokenMap.setItem(`${resource}:${scopes.join(_)}`, response.accessToken); return response.accessToken; } async getAccessToken(resource?:string, scopes?: string[]) { if (!this.idToken) { throw new Error('User not authenticated'); } const accessTokenInStorage = this.accessTokenMap.getItem(`${resource}:${scopes.join(_)}`); if (accessTokenInStorage && accessTokenInStorage.expiresAt > Date.now() / 1000) { return accessToken.token; } return await this.getAccessTokenByRefreshToken(resource, scopes); } ``` ## الخلاصة لقد قدمنا عمليات تنفيذ الأساليب الأساسية لمصادقة وتفويض المستخدم لتطبيق جانب العميل. بناءً على السيناريو المحدد لديك، يمكنك تنظيم وتحسين منطق SDK وفقًا لذلك. يرجى ملاحظة أنه قد توجد اختلافات بسبب المنصات والأطر المختلفة. لمزيد من التفاصيل، استعرض حزم SDK المقدمة من Logto. نشجع المزيد من المستخدمين على الانضمام إلى التطوير والمشاركة في المناقشات معنا. يتم تقييم ملاحظاتك ومساهماتك بشدة بينما نستمر في تحسين وتوسيع قدرات SDK. ## المُلحق ### النطاقات المحجوزة نطاقات Logto المحجوزة التي ستحتاج إلى تمريرها أثناء طلب التوثيق الأولي. هذه النطاقات إما محجوزة لـ OIDC أو محجوزة لـ Logto كقواعد أساسية لإكمال تدفق التفويض بنجاح. | اسم النطاق | الوصف | | -------------- | --------------------------------------------------------------------------------------------------------------------------------- | | openid | مطلوب لمنح `id_token` بعد مصادقة ناجحة. | | offline-access | مطلوب لمنح `refresh_token` الذي يسمح لتطبيق العميل الخاص بك بتبادل وتجديد access_token بدون ظهور. | | profile | مطلوب للوصول إلى المعلومات الأساسية للمستخدم | ### إعداد Logto | اسم الخاصية | النوع | مطلوب | الوصف | القيمة الافتراضية | | ------------- | ----------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- | | appId | string | true | معرف التطبيق الفريد. تم إنشاؤه من قبل خادم التفويض لتحديد تطبيق العميل. | | | appSecret | string | | سر التطبيق مستخدم، إلى جانب معرف التطبيق، للتحقق من هوية الطالب. إنه مطلوب للعملاء السريين مثل تطبيقات الويب Go أو Next.js، واختياري للعملاء العموميين مثل التطبيقات الأصلية أو التطبيقات ذات الصفحة الواحدة (SPAs) | | | endpoint | string | true | نقطة النهاية الجذرية لخادم التفويض الخاص بك. سيتم استخدام هذه الخاصية على نطاق واسع لإنشاء طلبات التفويض.endpoint. | | | scopes | string list | | يشير إلى جميع نطاقات الموارد الضرورية التي قد يحتاجها المستخدم ليكون معطى للوصول إلى أي موارد محمية معينة. | [reservedScopes] | | resources | string list | | جميع مؤشرات الموارد المحمية التي قد يطلب المستخدم الوصول إليها | | ### طرق المساعدة #### generateRandomString ```ts const generateRandomString = (length = 64) => fromUint8Array(crypto.getRandomValues(new Uint8Array(length)), true); ``` جرّب Logto Cloud اليوم