> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# إعداد تكامل Okta

> قم بربط Okta مع Living Security لإدارة دورة حياة المستخدم والمصادقة والمصادقة متعددة العوامل (MFA) والنشاط الإداري.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>موارد ذات صلة</h2>
    <ul>
      <li>
        <a href="/ar/signals/data-sources">تعرّف على كيفية تحويل بيانات التكاملات إلى إشارات إدارة المخاطر البشرية</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">استكشف تكاملات Living Security</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">افتح Living Security Platform</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">اطلب عرضًا توضيحيًا من Living Security</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>أضف عناوين IP الأربعة جميعها الخاصة بالمزامنة الصادرة من Living Security</strong> إلى قائمة السماح في{' '}
    {system}. أدخل كل عنوان كمضيف واحد مع <code>/32</code> إذا كان {system} يتوقع صيغة CIDR:
    <br />
    <code>52.34.139.153/32</code>, <code>54.69.127.183/32</code>, <code>44.247.133.183/32</code>,{' '}
    <code>52.26.211.56/32</code>
    <br />
    <br />
    يمكن أن تصدر حركة البيانات من أي عنوان من العناوين الأربعة، لذا فإن إضافة بعضها فقط إلى قائمة السماح يتسبب في إخفاقات متقطعة
    في المزامنة. هذه العناوين الأربعة هي نفسها في جميع مناطق Living Security. راجع{' '}
    <a href="/ar/integrations/managing/egress-ip-addresses">
      تكوين عناوين IP الصادرة للتكاملات
    </a>{' '}
    للاطلاع على القائمة الكاملة وسياسة التغيير واستكشاف الأخطاء وإصلاحها.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="أدخل بيانات الاعتماد في Living Security Platform">
    <p>
      يُنفَّذ هذا الإجراء من قِبل من يملك صلاحية الوصول إلى Living Security، وهو مالك البرنامج، أو مسؤول النظام
      إذا تمت دعوته (الإعداد المفوَّض).
    </p>
    <ol>
      <li>
        انتقل إلى <strong>الإعدادات ← التكاملات ← كتالوج</strong>، وحدد موضع بطاقة{' '}
        <strong>{tile}</strong>، ثم انقر فوق <strong>اتصال</strong>.
      </li>
      <li>
        املأ الحقول أدناه، ثم انقر فوق <strong>اتصال</strong>.
      </li>
    </ol>
    {children}
  </Step>;

## نظرة عامة

يمكن لـ Okta تقديم بيانات موحّدة عن دورة حياة المستخدم والمصادقة والمصادقة متعددة العوامل (MFA) والنشاط الإداري. تشمل الأمثلة التي تمت مراجعتها ما يلي:

* `account.locked` — تم قفل الحساب
* `mfa.factor.activated` — تفعيل عوامل MFA إضافية
* `auth.login.failed` — فشل تسجيل الدخول

تقرأ طريقتا الاتصال كلتاهما التدفقين نفسيهما — دليل المستخدمين (`/api/v1/users`) وسجل النظام (`/api/v1/logs`). راجع [كيف تتحول بيانات التكامل إلى إشارات](/ar/signals/data-sources).

## اختيار طريقة الاتصال

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| بيانات الاعتماد | رمز API تنشئه في Admin Console | معرف عميل ومفتاح JWK خاص تقوم بإنشائه وتسجيله |
| الإعداد | ثلاث خطوات، دون الحاجة إلى إنشاء مواد مفاتيح | تسع خطوات، تشمل إنشاء زوج مفاتيح RSA |
| دور المسؤول المطلوب | مسؤول بصلاحيات القراءة فقط، يُسند إلى مالك الرمز | مسؤول بصلاحيات القراءة فقط، يُسند إلى التطبيق |
| مدة صلاحية الرمز | يتم تعطيله بعد 30 يومًا من عدم الاستخدام | لا تنتهي صلاحيته؛ وتقع عليك مسؤولية تدوير زوج المفاتيح |
| متى تستخدمها | هذا هو المسار الموصى به لمعظم المؤسسات | تمنع سياسة الأمن لديك استخدام رموز API طويلة الأمد |

تتطلب الطريقتان مستوى الوصول نفسه، لذا يتعلق الاختيار بآلية التعامل مع بيانات الاعتماد، لا بما يمكن للمنصة قراءته.

***

## الخيار A — رمز API ‏(SSWS)

*موصى به.*

### ما تحتاجه Living Security

| بيانات الاعتماد | الوصف |
| - | - |
| **API key** | رمز API من Okta. تسمّي نافذة الاتصال هذا الحقل **API key** |
| **Tenant subdomain** | `<tenant>` في `<tenant>.okta.com` — النطاق الفرعي فقط، وليس عنوان URL الكامل |

### المتطلبات المسبقة

* يجب أن تكون **Super Administrator** في Okta لإنشاء مستخدم حساب خدمة، وإسناد أدوار المسؤولين، وإنشاء رموز API.

<Steps>
  <Step title="إنشاء مستخدم يمتلك الرمز">
    يحمل رمز API في Okta صلاحيات المستخدم الذي أنشأه، ويتوقف عن العمل إذا تم تعطيل ذلك المستخدم. أنشئ حساب خدمة مخصصًا بدلًا من استخدام حساب مسؤول شخصي، حتى يستمر الاتصال عند تغيّر الموظفين.

    1. في Admin Console، انتقل إلى **Directory** → **People**.
    2. انقر على **Add person** وأنشئ مستخدمًا مثل `svc-livingsecurity@yourcompany.com`.
    3. فعّل الحساب.
  </Step>

  <Step title="إسناد دور المسؤول بصلاحيات القراءة فقط">
    تقوم المنصة بالقراءة فقط. ومنح صلاحيات تتجاوز القراءة يمنح الرمز أذونات لا يستخدمها أبدًا.

    1. انتقل إلى **Security** → **Administrators**.
    2. انقر على **Add administrator** وحدد المستخدم الذي أنشأته في الخطوة السابقة.
    3. أسند دور **Read-only Administrator**.
    4. احفظ.

    <Note>
      بدون دور مسؤول، تنجح استدعاءات Okta Management API بالرمز `200 OK` وتعيد قائمة فارغة. ولا يوجد `403` يُنبّهك إلى غياب الدور — بل تبقى التدفقات فارغة ببساطة.
    </Note>
  </Step>

  <Step title="إنشاء رمز API">
    1. سجّل الدخول إلى Admin Console **بصفتك مستخدم حساب الخدمة** الذي أنشأته في الخطوة 1. يرث الرمز صلاحيات الحساب الذي ينشئه.
    2. انتقل إلى **Security** → **API** وافتح علامة التبويب **Tokens**.
    3. انقر على **Create token**، وأعطه اسمًا مثل `Living Security Platform`، ثم انقر على **Create token**.
    4. انسخ قيمة الرمز الآن — تعرضها Okta مرة واحدة فقط ولن تعرضها مجددًا.

    <Warning>
      تعطّل Okta رمز API بعد **30 يومًا من عدم الاستخدام**. تعمل عمليات المزامنة في هذا التكامل مرة واحدة على الأقل يوميًا، لذا يحافظ الاتصال النشط على صلاحية رمزه. أما الاتصال الذي يُترك متوقفًا لمدة شهر فيحتاج إلى رمز جديد.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      لا تهمّك قائمة العناوين أعلاه إلا إذا كانت مؤسسة Okta لديك تقيّد الوصول إلى API حسب **network zone**. ولا تفعل معظم المؤسسات ذلك.
    </Note>
  </Step>

  <Step title="العثور على النطاق الفرعي للمستأجر">
    يبدو عنوان URL الخاص بـ Admin Console لديك كما يلي: `https://acme-admin.okta.com`. النطاق الفرعي للمستأجر هو `acme` — بدون اللاحقة `-admin`، وبدون `.okta.com`، وبدون `https://`.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | الحقل | القيمة |
    | - | - |
    | **API key** | رمز API من الخطوة 3 |
    | **Tenant subdomain** | النطاق الفرعي من الخطوة 4 (مثل `acme`) |
  </ConnectInPlatform>
</Steps>

لقد تم الآن الاتصال بـ Okta (SSWS).

### استكشاف الأخطاء وإصلاحها

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    الرمز غير صالح، أو تم إبطاله، أو تم تعطيله بعد 30 يومًا من عدم النشاط. أنشئ رمزًا جديدًا بصفتك مستخدم حساب الخدمة وأعد إدخاله في الاتصال.
  </Accordion>

  <Accordion title="تم الاتصال، لكن جميع التدفقات فارغة">
    لا يملك مالك الرمز دور مسؤول. أسند دور **Read-only Administrator** إلى حساب الخدمة (الخطوة 2) — تعيد API الرمز `200 OK` مع قائمة فارغة بدلًا من خطأ عندما يكون الدور مفقودًا.
  </Accordion>

  <Accordion title="فشل عمليات المزامنة بعد تغيّر الموظفين">
    يتوقف الرمز عن العمل إذا تم تعطيل المستخدم الذي أنشأه. ولهذا ينبغي أن يتبع الرمز لحساب خدمة لا لشخص.
  </Accordion>
</AccordionGroup>

***

## الخيار B — تطبيق خدمة OAuth 2.0

استخدم هذه الطريقة عندما لا تسمح سياسة الأمن لديك برموز API طويلة الأمد. فهي تستبدل الرمز بمعرف عميل وزوج مفاتيح RSA تملكه. في المنصة، هذه هي البطاقة **Okta (OAuth 2.0)** ضمن **الإعدادات ← التكاملات ← كتالوج**.

للمصادقة مع Okta باستخدام Client Credentials، تحتاج إلى ما يلي:

1. **Client ID** - معرّف فريد لتطبيق Okta API Services الخاص بك.
2. **Private Key (JWK)** - مفتاح RSA الخاص بصيغة JSON Web Key، والذي يكون مفتاحه العام مسجلًا في تطبيق Okta الخاص بك.
3. **Okta Domain** - النطاق الفرعي لمستأجر Okta فقط (مثل `dev-12345678`)، وليس اسم المضيف الكامل.
4. **Scopes** - قائمة مفصولة بمسافات من نطاقات Okta Management API (مثل `okta.users.read okta.logs.read`).

سيرشدك هذا الدليل خلال إنشاء تطبيق API Services في Okta مع مصادقة `private_key_jwt`.

### المتطلبات المسبقة:

* يجب أن يكون لديك حساب Okta. يمكنك التسجيل للحصول على حساب مطوّر مجاني على [developer.okta.com](https://developer.okta.com/signup/).

#### الخطوة 1: إنشاء تطبيق Okta API Services

1. سجّل الدخول إلى [Okta Admin Console](https://login.okta.com/).
2. في الشريط الجانبي الأيسر، انتقل إلى **Applications** > **Applications**.
3. انقر على **Create App Integration**.
4. حدد **API Services** كطريقة تسجيل الدخول وانقر على **التالي**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-api-service.png" style={{maxWidth: "550px"}} />

5. أعطِ تطبيقك اسمًا وانقر على **حفظ**.
6. في علامة التبويب **General** الخاصة بالتطبيق، ابحث عن **معرف العميل** — ستحتاج إليه في الخطوة الأخيرة.
7. اضبط Client authentication على **Public key / Private key**. لا تُدعم نطاقات `okta.*` إلا مع طريقة المصادقة هذه.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/select-public-private-key.png" style={{maxWidth: "550px"}} />

8. عطّل **Proof of possession (DPoP)** — فهو غير مدعوم.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/disable-dpop.png" style={{maxWidth: "550px"}} />

<Note>
  يجب إنشاء التطبيق من النوع **API Services**.
</Note>

#### الخطوة 2: إنشاء زوج مفاتيح RSA وتسجيله

##### استخدام مولّد المفاتيح في Okta

يمكن لـ Okta إنشاء زوج مفاتيح RSA لك مباشرة في Admin Console:

1. في Admin Console، افتح تطبيق API Services الخاص بك.
2. انتقل إلى علامة التبويب **General** ومرّر إلى قسم **PUBLIC KEYS**.
3. انقر على **Add Key**، ثم حدد **Generate new key**.
4. انقر على **حفظ** — تنشئ Okta زوج المفاتيح وتعرض **Private Key (JWK)** مرة واحدة.
5. انسخ ملف JSON الخاص بالمفتاح الخاص واحفظه فورًا — فلن يُعرض مرة أخرى.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/create-public-key.png" style={{maxWidth: "550px"}} />

6. يتم تسجيل المفتاح العام تلقائيًا في تطبيقك.

<Note>
  انسخ مفتاح JWK الخاص قبل إغلاق مربع الحوار. والصقه في حقل **Private Key** في Living Security Platform في الخطوة الأخيرة.
</Note>

##### إنشاء مفتاحك الخاص

تستخدم Okta `private_key_jwt` لتطبيقات API Services. تقوم بإنشاء زوج مفاتيح RSA، وتسجّل مفتاح JWK **العام** لدى Okta، وتزوّد Living Security Platform بمفتاح JWK **الخاص**.

**أنشئ مفتاح JWK خاصًا** باستخدام نص Node.js البرمجي التالي (يتطلب Node.js 18+):

```javascript theme={null}
const { generateKeyPairSync } = require('crypto');
const { privateKey, publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });

const privateJwk = privateKey.export({ format: 'jwk' });
const publicJwk  = publicKey.export({ format: 'jwk' });

// Assign a kid — must match between private and public JWK
const kid = require('crypto').randomUUID();
privateJwk.kid = kid;
publicJwk.kid  = kid;

console.log('=== PUBLIC JWK (upload to Okta) ===');
console.log(JSON.stringify(publicJwk, null, 2));
console.log('\n=== PRIVATE JWK (paste into the Living Security Platform) ===');
console.log(JSON.stringify(privateJwk));
```

**سجّل مفتاح JWK العام في Okta:**

1. في Admin Console، افتح تطبيق API Services الخاص بك.
2. انتقل إلى علامة التبويب **General** ومرّر إلى قسم **PUBLIC KEYS**.
3. انقر على **Add Key**، والصق ناتج **JSON لمفتاح JWK العام** من النص البرمجي أعلاه، ثم انقر على **حفظ**.

<Note>
  مفتاح JWK الخاص هو ما تلصقه في Living Security Platform. ويتضمن جميع مواد المفتاح (`d`، `p`، `q`، `dp`، `dq`، `qi`) و`kid`. حافظ على سريته.
</Note>

#### الخطوة 3: العثور على Okta Domain

أدخل النطاق الفرعي لمستأجر Okta فقط — الجزء الذي يسبق `.okta.com`.

* في Admin Console، سيعرض شريط عنوان المتصفح عنوان URL مثل `https://dev-12345678-admin.okta.com`.
* **Okta Domain** الخاص بك هو النطاق الفرعي فقط (مثل `dev-12345678`)، وليس `dev-12345678.okta.com`.
* بدلًا من ذلك، انتقل إلى **الإعدادات** > **Account** في Admin Console للعثور على نطاق Okta الخاص بك، ثم استخدم جزء النطاق الفرعي.

#### الخطوة 4: منح نطاقات API لتطبيقك

تشترط Okta وجود نطاق واحد على الأقل في كل طلب رمز. قبل أن يتمكن تطبيقك من طلب نطاقات محددة، يجب منحها:

1. في Admin Console، انتقل إلى **Applications** > **Applications** وافتح تطبيقك.
2. انقر على علامة التبويب **Okta API Scopes**.
3. امنح النطاقات التي يتطلبها تكاملك: `okta.users.read` و`okta.logs.read`.

توجد قائمة كاملة بالنطاقات المتاحة في [مرجع Okta Management API](https://developer.okta.com/docs/api/oauth2/#okta-admin-management).

#### الخطوة 5: إسناد دور مسؤول إلى تطبيقك

منح النطاقات وحده لا يكفي — إذ تعيد نقاط نهاية Okta Management API (مثل `/api/v1/users`) استجابة `200 []` فارغة دون أي تنبيه إذا لم يكن لتطبيقك دور مسؤول. يجب إسناد **Read-Only Administrator** على الأقل:

1. في Admin Console، انتقل إلى **الأمن** > **Administrators** (أو انتقل إلى **Applications** > **Applications** > تطبيقك > **Admin roles**).
2. انقر على **Add administrator assignment** وحدد تطبيق API Services الخاص بك.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/admin-role-dropdown.png" style={{maxWidth: "550px"}} />

3. أسند دور **Read-Only Administrator** (أو دورًا أعلى، بحسب النطاقات التي تحتاجها).
4. انقر على **حفظ**.

<img src="https://raw.githubusercontent.com/NangoHQ/nango/master/docs/api-integrations/okta-cc/add-admin-role.png" style={{maxWidth: "550px"}} />

<Note>
  بدون دور مسؤول، تنجح استدعاءات API بالرمز `200 OK` لكنها تعيد نتائج فارغة، ولا يوجد خطأ `403` يشير إلى المشكلة.
</Note>

#### الخطوة 6: إدخال بيانات الاعتماد في Living Security Platform

بعد أن تحصل على **معرف العميل** و**Private Key (JWK)** و**Okta Domain** و**Scopes**:

1. افتح النموذج الذي تحتاج فيه إلى المصادقة مع Okta (Client Credentials).
2. أدخل **معرف العميل**.
3. الصق **Private Key (JWK)** — كائن JSON الكامل من النص البرمجي أعلاه (في سطر واحد أو منسّقًا).
4. أدخل **Okta Domain** على أنه النطاق الفرعي للمستأجر فقط (مثل `dev-12345678`).
5. أدخل **Scopes** كقائمة مفصولة بمسافات (مثل `okta.users.read okta.logs.read`).
6. أرسل النموذج، ومن المفترض أن تتم المصادقة بنجاح.

لقد تم الآن الاتصال بـ Okta (Client Credentials).

***

<Note>تم اقتباس أجزاء من هذا التوثيق بتصرف من [Nango](https://nango.dev/docs/)، وهي مستخدمة بموجب [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme).</Note>

<PublicIntegrationNextSteps />


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.