okta auth js
7.8.1
تعتمد حزمة Okta Auth JavaScript SDK على واجهة برمجة التطبيقات Authentication API وOpenID Connect & OAuth 2.0 API لتمكينك من إنشاء تجربة تسجيل دخول ذات علامة تجارية كاملة باستخدام JavaScript.
يمكنك معرفة المزيد على صفحة Okta + JavaScript في وثائقنا.
تستخدم هذه المكتبة الإصدارات الدلالية وتتبع سياسة إصدار مكتبة Okta.
️ ️ ️ ️ ️ ️ ️ ️ ️
️ ️ ️ ️ ️ ️ ️ ️ ️
✔️ سلسلة الإصدارات الرئيسية المستقرة الحالية هي: 7.x
| إصدار | حالة |
|---|---|
7.x | ✔️ مستقرة |
6.x | متقاعد |
5.x | متقاعد |
4.x | متقاعد |
3.x | متقاعد |
2.x | متقاعد |
1.x | متقاعد |
0.x | متقاعد |
يمكن دائمًا العثور على أحدث إصدار على صفحة الإصدارات.
إذا واجهت مشاكل في استخدام SDK، فيمكنك:
يجب على المستخدمين الذين يقومون بالترحيل من الإصدارات السابقة من SDK هذا الاطلاع على دليل الترحيل لمعرفة التغييرات الضرورية.
من المعروف أن حزمة تطوير البرامج (SDK) هذه تعمل مع الإصدارات الحالية من Chrome وFirefox وSafari على سطح المكتب والهاتف المحمول.
يمكن تحقيق التوافق مع IE 11 / Edge عن طريق إضافة حشوات/حشوات للكائنات التالية:
️ لا تستطيع عمليات التشفير المتعددة استخدام نظام التشغيل كمصدر للإنتروبيا عالية الجودة المستخدمة لإنشاء أرقام عشوائية زائفة تمثل مفتاح التشفير الجيد. على هذا النحو، فإننا نتخذ موقفًا مفاده أن عمليات تعبئة العملات المشفرة أقل أمانًا وننصح بعدم استخدامها.
توفر هذه الوحدة نقطة دخول تنفذ كافة عمليات التعبئة المتعددة المطلوبة.
إذا كنت تستخدم JS على صفحة ويب من المتصفح، فيمكنك نسخ محتويات node_modules/@okta/okta-auth-js/dist إلى الدليل المستضاف بشكل عام، وتضمين مرجع إلى okta-auth-js.polyfill.js ملف okta-auth-js.polyfill.js في علامة <script> . يجب أن يتم تحميله قبل أي نصوص برمجية أخرى تعتمد على polyfill.
إذا كنت تستخدم أداة تجميع مثل Webpack أو Browserify، فيمكنك ببساطة استيراد استيراد أو طلب @okta/okta-auth-js/polyfill عند بداية كود تطبيقك أو بالقرب منه:
import '@okta/okta-auth-js/polyfill' ;أو
require ( '@okta/okta-auth-js/polyfill' ) ;تتوفر أيضًا حزمة polyfill المدمجة على شبكة CDN العالمية الخاصة بنا. قم بتضمين البرنامج النصي التالي في ملف HTML الخاص بك ليتم تحميله قبل أي برامج نصية أخرى:
< script src =" https://global.oktacdn.com/okta-auth-js/7.5.1/okta-auth-js.polyfill.js " type =" text/javascript " integrity =" sha384-EBFsuVdi4TGp/DwS7b+t+wA8zmWK10omkX05ZjJWQhzWuW31t7FWEGOnHQeIr8+L " crossorigin =" anonymous " > </ script >
️ قد يكون الإصدار الموضح في هذه العينة أقدم من الإصدار الحالي. نوصي باستخدام أعلى إصدار متاح
بدأت العديد من المتصفحات في حظر ملفات تعريف الارتباط المشتركة المصدر أو "الطرف الثالث" افتراضيًا. على الرغم من أن معظم واجهات برمجة تطبيقات Okta التي يدعمها SDK هذا لا تعتمد على ملفات تعريف الارتباط، إلا أن هناك بعض الطرق التي تفعل ذلك. سيتم إيقاف هذه الطرق إذا تم حظر ملفات تعريف الارتباط الخاصة بالطرف الثالث:
إذا كان تطبيقك يعتمد على أي من هذه الطرق، فيجب عليك إما محاولة إعادة كتابة تطبيقك لتجنب استخدام هذه الطرق أو إبلاغ المستخدمين بضرورة تمكين ملفات تعريف الارتباط الخاصة بالطرف الثالث. يعمل مهندسو Okta حاليًا على إيجاد حل أفضل طويل المدى لهذه المشكلة.
يعد تثبيت Authentication SDK أمرًا بسيطًا. يمكنك تضمينه في مشروعك عبر حزمة npm الخاصة بنا، @okta/okta-auth-js.
ستحتاج أيضًا إلى:
عند إنشاء تطبيق Okta جديد، يمكنك تحديد نوع التطبيق. تم تصميم SDK هذا للعمل مع SPA (تطبيقات الصفحة الواحدة) أو تطبيقات Web . سيقوم تطبيق SPA بتنفيذ جميع التدفقات المنطقية والتفويضية من جانب العميل. سيقوم تطبيق Web بإجراء تدفقات التفويض على الخادم.
من واجهة مستخدم Okta Admin، انقر فوق Applications ، ثم حدد التطبيق الخاص بك. يمكنك عرض وتحرير تكوين تطبيق Okta الخاص بك ضمن علامة التبويب General بالتطبيق.
سلسلة تحدد تطبيق Okta الخاص بك بشكل فريد.
لتسجيل دخول المستخدمين، يقوم تطبيقك بإعادة توجيه المتصفح إلى صفحة تسجيل الدخول التي تستضيفها Okta. تقوم Okta بعد ذلك بإعادة التوجيه مرة أخرى إلى تطبيقك بمعلومات حول المستخدم. يمكنك معرفة المزيد حول كيفية عمل ذلك على التدفقات التي تستضيفها Okta.
تحتاج إلى إضافة عنوان URL لإعادة توجيه تسجيل الدخول إلى القائمة البيضاء في إعدادات تطبيق Okta.
بعد تسجيل خروج المستخدمين من تطبيقك وخروجهم من Okta، يتعين عليك إعادة توجيه المستخدمين إلى موقع محدد في تطبيقك. تحتاج إلى إدراج عنوان URL لتسجيل الخروج في القائمة البيضاء في إعدادات تطبيق Okta.
يعد استخدام وحدة npm الخاصة بنا خيارًا جيدًا إذا:
لتثبيت @okta/okta-auth-js:
# Run this command in your project root folder.
# yarn
yarn add @okta/okta-auth-js
# npm
npm install --save @okta/okta-auth-js إذا كنت تستخدم JS على صفحة ويب من المتصفح، فيمكنك نسخ محتويات node_modules/@okta/okta-auth-js/dist إلى الدليل المستضاف بشكل عام، وتضمين مرجع إلى okta-auth-js.min.js ملف okta-auth-js.min.js في علامة <script> .
تتوفر أيضًا حزمة المكتبة المضمنة على شبكة CDN العالمية الخاصة بنا. قم بتضمين البرنامج النصي التالي في ملف HTML الخاص بك ليتم تحميله قبل البرنامج النصي للتطبيق الخاص بك:
< script src =" https://global.oktacdn.com/okta-auth-js/7.5.1/okta-auth-js.min.js " type =" text/javascript " integrity =" sha384-6epSwnIDkI5zFNEVNjEYy3A7aSZ+C7ehmEyG8zDJZfP9Bmnxc51TK8du+2me4pjb " crossorigin =" anonymous " > </ script >
️ قد يكون الإصدار الموضح في هذه العينة أقدم من الإصدار الحالي. نوصي باستخدام أعلى إصدار متاح
ثم يمكنك إنشاء مثيل لكائن OktaAuth ، المتوفر عالميًا.
const oktaAuth = new OktaAuth ( {
// config
} )ومع ذلك، إذا كنت تستخدم أداة تجميع مثل Webpack أو Rollup، فيمكنك ببساطة استيراد الوحدة أو طلبها.
// ES module
import { OktaAuth } from '@okta/okta-auth-js'
const authClient = new OktaAuth ( /* configOptions */ ) // CommonJS
var OktaAuth = require ( '@okta/okta-auth-js' ) . OktaAuth ;
var authClient = new OktaAuth ( /* configOptions */ ) ; للحصول على نظرة عامة على ميزات العميل وتدفقات المصادقة، راجع مستندات المطورين لدينا. هناك، سوف تتعلم كيفية استخدام Auth SDK على صفحة ثابتة بسيطة من أجل:
️ قد تتم كتابة مستندات المطور لإصدار سابق من هذه المكتبة. راجع الترحيل من الإصدارات السابقة.
يمكنك أيضًا تصفح الوثائق المرجعية الكاملة لواجهة برمجة التطبيقات (API).
⌛ تُرجع الأساليب غير المتزامنة وعدًا سيتم حله عند النجاح. قد يتم رفض الوعد في حالة حدوث خطأ.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
} ;
var authClient = new OktaAuth ( config ) ; افتراضيًا، لن يؤدي إنشاء مثيل جديد لـ OktaAuth إلى إنشاء أي آثار جانبية غير متزامنة. ومع ذلك، تتطلب بعض الميزات، مثل التجديد التلقائي للرمز المميز والإزالة التلقائية للرمز المميز والمزامنة عبر علامات التبويب، تشغيل OktaAuth كخدمة. وهذا يعني أنه يتم تعيين المهلات في الخلفية والتي ستستمر في العمل حتى يتم إيقاف الخدمة. لبدء خدمة OktaAuth ، ما عليك سوى استدعاء طريقة start مباشرة بعد الإنشاء وقبل استدعاء طرق أخرى مثل HandleRedirect. لإنهاء جميع العمليات في الخلفية، قم باستدعاء stop . راجع تكوين الخدمة لمزيد من المعلومات.
var authClient = new OktaAuth ( config ) ;
await authClient . start ( ) ; // start the service
await authClient . stop ( ) ; // stop the serviceملاحظة: سيؤدي بدء الخدمة أيضًا إلى استدعاء authStateManager.updateAuthState.
يتم توفير تعريفات النوع ضمنيًا من خلال إدخال types في package.json . يمكن أيضًا الإشارة إلى الأنواع بشكل صريح عن طريق استيرادها.
import {
OktaAuth ,
OktaAuthOptions ,
TokenManagerInterface ,
AccessToken ,
IDToken ,
UserClaims ,
TokenParams
} from '@okta/okta-auth-js' ;
const config : OktaAuthOptions = {
issuer : 'https://{yourOktaDomain}'
} ;
const authClient : OktaAuth = new OktaAuth ( config ) ;
const tokenManager : TokenManagerInterface = authClient . tokenManager ;
const accessToken : AccessToken = await tokenManager . get ( 'accessToken' ) as AccessToken ;
const idToken : IDToken = await tokenManager . get ( 'idToken' ) as IDToken ;
const userInfo : UserClaims = await authClient . token . getUserInfo ( accessToken , idToken ) ;
if ( ! userInfo ) {
const tokenParams : TokenParams = {
scopes : [ 'openid' , 'email' , 'custom_scope' ] ,
} ;
authClient . token . getWithRedirect ( tokenParams ) ;
} لا تحتوي إصدارات Typescript الأقدم من 3.6 على تعريفات نوع لـ WebAuthn. تم تقديم دعم WebAuthn في IDX API في @okta/[email protected] . لحل هذه المشكلة، يرجى تثبيت الحزمة @types/webappsec-credential-management version ^0.5.1 .
يمكن لعملاء الويب والعملاء الأصليين الحصول على الرموز المميزة باستخدام تدفق authorization_code الذي يستخدم سر العميل المخزن في مكان آمن. (يجب أن تستخدم تطبيقات SPA تدفق PKCE الذي لا يستخدم سر العميل) لاستخدام تدفق authorization_code ، قم بتعيين responseType على "code" و pkce على false :
var config = {
// Required config
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
// Use authorization_code flow
responseType : 'code' ,
pkce : false
} ;
var authClient = new OktaAuth ( config ) ; سيتم استخدام تدفق PKCE OAuth بشكل افتراضي. تدعم هذه المكتبة PKCE لكل من المتصفح وتطبيقات NodeJS. يتم دعم PKCE على نطاق واسع بواسطة معظم المتصفحات الحديثة عند تشغيله على اتصال HTTPS. يتطلب PKCE أن يقوم المتصفح بتنفيذ crypto.subtle (المعروف أيضًا باسم webcrypto ). توفر معظم المتصفحات الحديثة هذا عند التشغيل في سياق آمن (على اتصال HTTPS). يتطلب PKCE أيضًا كائن TextEncoder. يتوفر هذا على جميع المتصفحات الرئيسية باستثناء IE 11 وEdge <v79. لإضافة دعم، نوصي باستخدام حشوة/حشوة مثل ترميز النص.
إذا كان متصفح المستخدم لا يدعم PKCE، فسيتم طرح استثناء. يمكنك اختبار ما إذا كان المتصفح يدعم PKCE قبل الإنشاء باستخدام هذه الطريقة الثابتة:
OktaAuth.features.isPKCESupported()
️ نحن لا نشجع بشدة على استخدام التدفق الضمني. استخدم PKCE و/أو بيانات اعتماد العميل إن أمكن.
يتوفر تدفق OAuth الضمني كخيار إذا لم يكن من الممكن دعم تدفق PKCE في النشر الخاص بك. وهو مدعوم على نطاق واسع من قبل معظم المتصفحات، ويمكن أن يعمل عبر اتصال HTTP غير آمن. لاحظ أن التدفق الضمني أقل أمانًا من تدفق PKCE، حتى عبر HTTPS، نظرًا لأن الرموز المميزة الأولية يتم كشفها في سجل المتصفح. لهذا السبب، نوصي بشدة باستخدام تدفق PKCE إن أمكن.
يمكن تمكين التدفق الضمني عن طريق ضبط خيار pkce على false
var config = {
pkce : false ,
// other config
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
} ;
var authClient = new OktaAuth ( config ) ;لتسجيل دخول مستخدم، يجب أن يقوم تطبيقك بإعادة توجيه المتصفح إلى صفحة تسجيل الدخول التي تستضيفها Okta.
ملاحظة: تؤدي عملية إعادة التوجيه الأولية إلى صفحة تسجيل الدخول التي تستضيفها Okta إلى بدء معاملة مع تعيين عمر StateToken على ساعة واحدة.
بعد المصادقة الناجحة، تتم إعادة توجيه المتصفح مرة أخرى إلى التطبيق الخاص بك مع معلومات حول المستخدم. اعتمادا على تفضيلاتك، من الممكن استخدام استراتيجيات رد الاتصال التالية.
ستتعامل معظم التطبيقات مع رد اتصال OAuth باستخدام مسار/صفحة خاصة، منفصلة عن صفحة تسجيل الدخول. ومع ذلك، فإن بعض تطبيقات SPA ليس لها منطق توجيه وستحتاج إلى التعامل مع كل شيء في صفحة واحدة.
async function main ( ) {
// create OktaAuth instance
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default' ,
clientId : 'GHtf9iJdr60A9IYrR0jw' ,
redirectUri : 'https://acme.com/oauth2/callback/home' ,
} ;
authClient = new OktaAuth ( config ) ;
// Subscribe to authState change event.
authClient . authStateManager . subscribe ( function ( authState ) {
// Logic based on authState is done here.
if ( ! authState . isAuthenticated ) {
// render unathenticated view
return ;
}
// Render authenticated view
} ) ;
// Handle callback
if ( authClient . token . isLoginRedirect ( ) ) {
const { tokens } = await authClient . token . parseFromUrl ( ) ; // remember to "await" this async call
authClient . tokenManager . setTokens ( tokens ) ;
}
// normal app startup
authClient . start ( ) ; // will update auth state and call event listeners
} وفقًا لمواصفات OAuth 2.0، فإن URI لإعادة التوجيه "يجب ألا يحتوي على مكون جزء": https://tools.ietf.org/html/rfc6749#section-3.1.2 عند استخدام إستراتيجية توجيه التجزئة/الجزء وOAuth 2.0، فإن سيكون رد الاتصال بإعادة التوجيه هو المسار الرئيسي/الافتراضي. سيكون تدفق رد الاتصال لإعادة التوجيه مشابهًا جدًا للتعامل مع رد الاتصال دون توجيه. نوصي بتحديد المنطق الذي سيحلل عنوان URL لإعادة التوجيه في بداية تطبيقك، قبل أي عمليات تحقق أخرى من التفويض.
بالإضافة إلى ذلك، في حالة استخدام توجيه التجزئة، نوصي باستخدام "استعلام" PKCE وresponseMode (هذا هو الإعداد الافتراضي لـ PKCE). مع التدفق الضمني، قد تؤدي الرموز المميزة الموجودة في التجزئة إلى نتائج غير متوقعة نظرًا لأن أجهزة توجيه التجزئة قد تعيد كتابة الجزء.
TokenManager : tokenManager.setTokensالمرجع: DPoP (إثبات إثبات الحيازة) - RFC9449
DPoP في تطبيق Okta الخاص بك (الدليل: تكوين DPoP)https مطلوب. مطلوب سياق آمن لـ WebCrypto.subtleIndexedDB (MDN، caniuse) const config = {
// other configurations
pkce : true , // required
dpop : true ,
} ;
const authClient = new OktaAuth ( config ) ; المرجع: نظام مصادقة DPoP (RFC9449)
GET /protectedresource HTTP/1.1
Host: resource.example.org
Authorization: DPoP Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsIm...
async function dpopAuthenticatedFetch ( url , options ) {
const { method } = options ;
const dpop = await authClient . getDPoPAuthorizationHeaders ( { url , method } ) ;
// dpop = { Authorization: "DPoP token****", Dpop: "proof****" }
const headers = new Headers ( { ... options . headers , ... dpop } ) ;
return fetch ( url , { ... options , headers } ) ;
} use_dpop_nonceالمرجع: المصدر الوحيد المقدم من خادم المورد (RFC9449)
يمكن لخوادم الموارد أيضًا اختيار توفير قيمة nonce ليتم تضمينها في أدلة DPoP المرسلة إليهم. إنهم يوفرون الرقم باستخدام رأس DPoP-Nonce بنفس الطريقة التي تعمل بها خوادم التفويض...
HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="use_dpop_nonce",
error_description="Resource server requires nonce in DPoP proof"
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
async function dpopAuthenticatedFetch ( url , options ) {
// ...previous example...
const resp = await fetch ( url , { ... options , headers } ) ;
// resp = HTTP/1.1 401 Unauthorized...
if ( ! resp . ok ) {
const nonce = authClient . parseUseDPoPNonceError ( resp . headers ) ;
if ( nonce ) {
const retryDpop = await authClient . getDPoPAuthorizationHeaders ( { url , method , nonce } ) ;
const retryHeaders = new Headers ( { ... options . headers , ... retryDpop } ) ;
return fetch ( url , { ... options , headers : retryHeaders } ) ;
}
}
return resp ;
} يتطلب DPoP ميزات متصفح معينة. لن يتمكن المستخدم الذي يستخدم متصفحًا بدون الميزات المطلوبة من إكمال طلب الرموز المميزة. يوصى بالتحقق من دعم المتصفح أثناء تشغيل التطبيق.
// App.tsx
useEffect ( ( ) => {
if ( ! authClient . features . isDPoPSupported ( ) ) {
// user will be unable to request tokens
navigate ( '/unsupported-error-page' ) ;
}
} , [ ] ) ; يتطلب DPoP إنشاء CryptoKeyPair الذي يجب أن يستمر في التخزين. ستؤدي طرق مثل signOut() أو revokeAccessToken() إلى مسح زوج المفاتيح، ولكن لا يقوم المستخدمون دائمًا بتسجيل الخروج بشكل صريح. ولذلك، فمن الممارسات الجيدة مسح مساحة التخزين قبل تسجيل الدخول لمسح أي أزواج مفاتيح معزولة تم إنشاؤها من الرموز المميزة المطلوبة مسبقًا.
async function login ( options ) {
await authClient . clearDPoPStorage ( ) ; // clear possibly orphaned key pairs
return authClient . signInWithRedirect ( options ) ;
} سواء كنت تستخدم مجموعة تطوير البرامج (SDK) هذه لتنفيذ تدفق OIDC أو للتواصل مع Authentication API، فإن خيار التكوين الوحيد المطلوب هو issuer ، وهو عنوان URL لخادم تفويض Okta
يمكنك استخدام عنوان URL الخاص بمؤسسة Okta الخاصة بك باعتبارها جهة الإصدار. سيؤدي هذا إلى تطبيق سياسة التفويض الافتراضية وإصدار الرموز المميزة على مستوى المؤسسة.
var config = {
issuer : 'https://{yourOktaDomain}'
} ;
var authClient = new OktaAuth ( config ) ;يتيح لك Okta إنشاء العديد من خوادم ترخيص OAuth 2.0 المخصصة التي يمكنك استخدامها لحماية خوادم الموارد الخاصة بك. داخل كل خادم ترخيص، يمكنك تحديد نطاقات OAuth 2.0 والمطالبات وسياسات الوصول الخاصة بك. تمتلك العديد من المؤسسات خادم ترخيص "افتراضي".
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/default'
} ;
var authClient = new OktaAuth ( config ) ;يمكنك أيضًا إنشاء وتخصيص خوادم ترخيص إضافية.
var config = {
issuer : 'https://{yourOktaDomain}/oauth2/custom-auth-server-id'
} ;
var authClient = new OktaAuth ( config ) ; يمكن تضمين هذه الخيارات عند إنشاء نسخة Okta Auth JS ( new OktaAuth(config) ).
issuer
️ هذا الخيار مطلوب
عنوان URL لمؤسسة Okta الخاصة بك أو خادم مصادقة Okta. عن المصدر
clientIdمعرف العميل المسجل مسبقًا لدى Okta لتدفق مصادقة OIDC. إنشاء تطبيق Okta الخاص بك
redirectUri عنوان URL الذي تتم إعادة التوجيه إليه عند استخدام token.getWithRedirect . يجب أن يتم إدراج ذلك في عناوين URI الخاصة بإعادة توجيه تسجيل الدخول لتطبيق Okta. إذا لم يتم توفير redirectUri ، فسيتم تعيينه افتراضيًا على الأصل الحالي ( window.location.origin ). تكوين تطبيق Okta الخاص بك
postLogoutRedirectUri حدد عنوان URL الذي يجب إعادة توجيه المتصفح إليه بعد تسجيل الخروج. يجب أن يتم إدراج عنوان URL هذا في عناوين URL لإعادة توجيه تسجيل الخروج الخاصة بتطبيق Okta. إذا لم يتم تحديده، فسيتم استخدام أصل تطبيقك ( window.location.origin ). تكوين تطبيق Okta الخاص بك |
scopes حدد المعلومات التي تريد إتاحتها في id_token أو access_token الذي تم إرجاعه. بالنسبة لـ OIDC، يجب عليك تضمين openid كأحد النطاقات. الإعدادات الافتراضية هي ['openid', 'email'] . للحصول على قائمة بالنطاقات المتاحة، راجع النطاقات والمطالبات
stateسلسلة مقدمة من العميل سيتم تمريرها إلى نقطة نهاية الخادم وإرجاعها في استجابة OAuth. يمكن استخدام القيمة للتحقق من صحة استجابة OAuth ومنع تزوير الطلب عبر المواقع (CSRF). الافتراضيات لسلسلة عشوائية.
pkce القيمة الافتراضية true والتي تمكن PKCE OAuth Flow. لاستخدام التدفق الضمني أو تدفق رمز التفويض، اضبط pkce على false .
dpop القيمة الافتراضية false . اضبط على true لتمكين DPoP (إظهار إثبات الحيازة (RFC9449))
راجع الدليل: تمكين DPoP
عند طلب الرموز المميزة باستخدام token.getWithRedirect، سيتم إرجاع القيم كمعلمات ملحقة بـ redirectUri.
في معظم الحالات، لن تحتاج إلى تعيين قيمة لـ responseMode . يتم تعيين الإعدادات الافتراضية وفقًا لمواصفات OpenID Connect 1.0.
بالنسبة لتدفق PKCE OAuth)، سيكون رمز التفويض موجودًا في استعلام البحث لعنوان URL. يمكن للعملاء الذين يستخدمون تدفق PKCE اختيار تلقي رمز التفويض في جزء التجزئة بدلاً من ذلك عن طريق تعيين خيار ResponseMode على "جزء".
بالنسبة لتدفق OAuth الضمني)، ستكون الرموز المميزة في جزء التجزئة الخاص بعنوان URL. لا يمكن تغيير هذا.
responseType حدد نوع الاستجابة لمصادقة OIDC عند استخدام تدفق OAuth الضمني. القيمة الافتراضية هي ['token', 'id_token'] والتي ستطلب رمز وصول ورمز معرف مميز. إذا كان pkce true ، فسيتم طلب كل من رمز الوصول والمعرف وسيتم تجاهل هذا الخيار. بالنسبة لتطبيقات الويب/الأصلية التي تستخدم تدفق authorization_code ، يجب تعيين هذه القيمة على "code" ويجب تعيين pkce على false .
authorizeUrlحدد AuthorizeUrl مخصصًا لتنفيذ تدفق OIDC. الإعدادات الافتراضية للمصدر بالإضافة إلى "/v1/authorize".
userinfoUrlحدد userinfoUrl مخصصًا. الإعدادات الافتراضية للمصدر بالإضافة إلى "/v1/userinfo".
tokenUrlحدد رمزًا مميزًا مخصصًا. الإعدادات الافتراضية للمصدر بالإضافة إلى "/v1/token".
ignoreSignature
️ يجب استخدام هذا الخيار فقط لدعم المتصفح ولأغراض الاختبار.
يتم التحقق من صحة توقيعات رمز المعرف بشكل افتراضي عند استدعاء token.getWithoutPrompt و token.getWithPopup و token.getWithRedirect و token.verify . لتعطيل التحقق من صحة توقيع رمز التعريف لهذه الطرق، قم بتعيين هذه القيمة إلى true .
maxClockSkewالقيمة الافتراضية هي 300 (خمس دقائق). هذا هو الحد الأقصى للفرق المسموح به بين ساعة العميل وساعة Okta، بالثواني، عند التحقق من صحة الرموز. لا يوصى بتعيين هذا على 0، لأنه يزيد من احتمالية فشل التحقق من صحة الرموز المميزة الصالحة.
ignoreLifetime
️ يعمل هذا الخيار على تعطيل التحقق من عمر الرمز المميز، مما قد يؤدي إلى حدوث مشكلات تتعلق بالثغرة الأمنية. يجب استخدام هذا الخيار لغرض الاختبار. يرجى معالجة الخطأ في التطبيق الخاص بك لبيئة الإنتاج.
يتم التحقق من عمر الرمز المميز باستخدام maxClockSkew. لتجاوز هذا وتعطيل التحقق من صحة الرمز المميز، قم بتعيين هذه القيمة إلى true .
transformAuthState وظيفة رد الاتصال. عندما يتم استدعاء updateAuthState، يتم إنشاء كائن authState جديد. يتيح لك توفير وظيفة transformAuthState تعديل هذا الكائن أو استبداله قبل تخزينه وإصداره. إحدى حالات الاستخدام الشائعة هي تغيير معنى isAuthenticated. افتراضيًا، سيقوم updateAuthState بتعيين authState.isAuthenticated على true إذا كانت الرموز المميزة غير منتهية الصلاحية متاحة من tokenManager. يمكن تخصيص هذا المنطق ليتطلب أيضًا جلسة Okta SSO صالحة:
const config = {
// other config
transformAuthState : async ( oktaAuth , authState ) => {
if ( ! authState . isAuthenticated ) {
return authState ;
}
// extra requirement: user must have valid Okta SSO session
const 
