> ## 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 entegrasyonu kurulumu

> Kullanıcı yaşam döngüsü, kimlik doğrulama, MFA ve yönetimsel etkinlik için Okta'yı Living Security ile bağlayın.

export const PublicIntegrationNextSteps = () => <>
    <hr />
    <h2>İlgili kaynaklar</h2>
    <ul>
      <li>
        <a href="/tr/signals/data-sources">Entegrasyon verilerinin İnsan Riski Yönetimi sinyallerine nasıl dönüştüğünü öğrenin</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/integrations">Living Security entegrasyonlarını keşfedin</a>
      </li>
      <li>
        <a href="https://app.livingsecurity.ai/">Living Security Platform'u açın</a>
      </li>
      <li>
        <a href="https://www.livingsecurity.com/request-demo/">Living Security demosu talep edin</a>
      </li>
    </ul>
  </>;

export const EgressIpSafelist = ({system}) => <Note>
    <strong>Living Security eşitleme çıkış IP adreslerinin dördünü de</strong> {system} içindeki izin listesine ekleyin. {system} CIDR gösterimi bekliyorsa her adresi tek bir ana bilgisayar olarak <code>/32</code> ile girin:
    <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 />
    Trafik dört adresten herhangi birinden çıkabilir; bu nedenle yalnızca bazılarını izin listesine eklemek aralıklı eşitleme hatalarına yol açar. Bu dört adres, Living Security'nin tüm bölgelerinde aynıdır. Tam liste, değişiklik politikası ve sorun giderme için{' '}
    <a href="/tr/integrations/managing/egress-ip-addresses">
      Entegrasyon Çıkış IP Adreslerini Yapılandırma
    </a>{' '}
    sayfasına bakın.
  </Note>;

export const ConnectInPlatform = ({tile, children}) => <Step title="Living Security Platform'da kimlik bilgilerini girin">
    <p>
      Bu adım, Living Security erişimine sahip kişi tarafından tamamlanır: program sahibi veya davet edilmişse sistem
      yöneticisi (yetki devredilmiş kurulum).
    </p>
    <ol>
      <li>
        <strong>Ayarları → Entegrasyonları → Kataloğu</strong> bölümüne gidin, <strong>{tile}</strong>{' '}
        kutucuğunu bulun ve <strong>Bağlantısı</strong> düğmesine tıklayın.
      </li>
      <li>
        Aşağıdaki alanları doldurun, ardından <strong>Bağlantısı</strong> düğmesine tıklayın.
      </li>
    </ol>
    {children}
  </Step>;

## Genel Bakış

Okta, normalleştirilmiş kullanıcı yaşam döngüsü, kimlik doğrulama, MFA ve yönetimsel etkinlik verileri sağlayabilir. İncelenen örnekler şunlardır:

* `account.locked` — hesap kilitlendi
* `mfa.factor.activated` — ek MFA faktörlerini etkinleştirir
* `auth.login.failed` — oturum açamıyor

Her iki bağlantı yöntemi de aynı iki akışı okur: kullanıcı dizini (`/api/v1/users`) ve sistem günlüğü (`/api/v1/logs`). Bkz. [entegrasyon verilerinin sinyallere nasıl dönüştüğü](/tr/signals/data-sources).

## Bağlantı yöntemini seçin

| | **Okta (SSWS)** | **Okta (OAuth 2.0)** |
| - | - | - |
| Kimlik bilgisi | Admin Console'da oluşturduğunuz bir API belirteci | Oluşturup kaydettiğiniz bir istemci kimliği ve özel bir JWK |
| Kurulum | Üç adım, oluşturulacak anahtar materyali yok | RSA anahtar çifti dahil dokuz adım |
| Gerekli yönetici rolü | Salt okunur yönetici, belirteç sahibine atanır | Salt okunur yönetici, uygulamaya atanır |
| Belirteç ömrü | 30 gün kullanılmazsa devre dışı bırakılır | Süre sonu yoktur; anahtar çiftini döndürmek sizin sorumluluğunuzdadır |
| Ne zaman kullanılmalı | Çoğu kuruluş için önerilen yöntemdir | Güvenlik politikanız uzun ömürlü API belirteçlerini yasaklıyorsa |

Her iki yöntem de aynı erişimi gerektirir; dolayısıyla seçim, platformun neleri okuyabileceğiyle değil, kimlik bilgilerinin nasıl yönetildiğiyle ilgilidir.

***

## Seçenek A — API belirteci (SSWS)

*Önerilir.*

### Living Security'nin ihtiyaç duyduğu bilgiler

| Kimlik bilgisi | Açıklama |
| - | - |
| **API anahtarı** | Bir Okta API belirteci. Bağlantı iletişim kutusu bu alanı **API anahtarı** olarak adlandırır |
| **Tenant subdomain** | `<tenant>.okta.com` içindeki `<tenant>` — tam URL değil, yalnızca alt alan adı |

### Ön koşullar

* Bir hizmet hesabı kullanıcısı oluşturmak, yönetici rolleri atamak ve API belirteçleri oluşturmak için Okta **Super Administrator** olmanız gerekir.

<Steps>
  <Step title="Belirteci barındıracak bir kullanıcı oluşturun">
    Bir Okta API belirteci, onu oluşturan kullanıcının izinlerini taşır ve bu kullanıcı devre dışı bırakılırsa çalışmayı durdurur. Bağlantının personel değişikliklerinden etkilenmemesi için kişisel bir yönetici hesabı kullanmak yerine ayrı bir hizmet hesabı oluşturun.

    1. Admin Console'da **Directory** → **People** yolunu izleyin.
    2. **Add person** öğesine tıklayın ve `svc-livingsecurity@yourcompany.com` gibi bir kullanıcı oluşturun.
    3. Hesabı etkinleştirin.
  </Step>

  <Step title="Salt okunur yönetici rolünü atayın">
    Platform yalnızca okuma yapar. Okuma erişiminden fazlasını vermek, belirtece hiç kullanmayacağı izinler tanımlar.

    1. **Security** → **Administrators** yolunu izleyin.
    2. **Add administrator** öğesine tıklayın ve önceki adımdaki kullanıcıyı seçin.
    3. **Read-only Administrator** rolünü atayın.
    4. Save.

    <Note>
      Yönetici rolü olmadan, Okta Management API çağrıları `200 OK` ile başarılı olur ve boş bir liste döndürür. Rolün eksik olduğunu bildiren bir `403` yoktur; akışlar yalnızca boş kalır.
    </Note>
  </Step>

  <Step title="API belirtecini oluşturun">
    1. 1. adımdaki hizmet hesabı kullanıcısı **olarak** Admin Console'da oturum açın. Belirteç, hangi hesap tarafından oluşturulursa onun yetkilerini devralır.
    2. **Security** → **API** yolunu izleyin ve **Tokens** sekmesini açın.
    3. **Create token** öğesine tıklayın, belirtece `Living Security Platform` gibi bir ad verin ve **Create token** öğesine tıklayın.
    4. Belirteç değerini hemen kopyalayın; Okta bu değeri yalnızca bir kez gösterir, bir daha göstermez.

    <Warning>
      Okta, bir API belirtecini **30 gün kullanılmazsa** devre dışı bırakır. Bu entegrasyondaki senkronizasyonlar günde en az bir kez çalışır; dolayısıyla etkin bir bağlantı kendi belirtecini canlı tutar. Bir ay boyunca duraklatılmış bırakılan bir bağlantı için yeni bir belirteç gerekir.
    </Warning>

    <EgressIpSafelist system="Okta" />

    <Note>
      Yukarıdaki adres listesi yalnızca Okta kuruluşunuz API erişimini **ağ bölgesi** ile kısıtlıyorsa önemlidir. Çoğu kuruluş bunu yapmaz.
    </Note>
  </Step>

  <Step title="Tenant alt alan adınızı bulun">
    Admin Console URL'niz `https://acme-admin.okta.com` gibi görünür. Tenant alt alan adı `acme` kısmıdır; `-admin` son eki, `.okta.com` ve `https://` olmadan.
  </Step>

  <ConnectInPlatform tile="Okta (SSWS)">
    | Alan | Değer |
    | - | - |
    | **API anahtarı** | 3. adımdaki API belirteci |
    | **Tenant subdomain** | 4. adımdaki alt alan adı (ör. `acme`) |
  </ConnectInPlatform>
</Steps>

Artık Okta (SSWS) ile bağlantı kurdunuz.

### Sorun Giderme

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    Belirteç geçersiz, iptal edilmiş veya 30 günlük işlemsizlik sonrasında devre dışı bırakılmıştır. Hizmet hesabı kullanıcısı olarak yeni bir belirteç oluşturun ve bağlantıya yeniden girin.
  </Accordion>

  <Accordion title="Bağlandı, ancak tüm akışlar boş">
    Belirteç sahibinin yönetici rolü yoktur. Hizmet hesabına **Read-only Administrator** rolünü atayın (2. adım); rol eksik olduğunda API hata vermek yerine boş bir liste ile `200 OK` döndürür.
  </Accordion>

  <Accordion title="Personel değişikliğinden sonra senkronizasyonlar başarısız oluyor">
    Belirteci oluşturan kullanıcı devre dışı bırakılırsa belirteç çalışmayı durdurur. Bu nedenle belirteç bir kişiye değil, bir hizmet hesabına ait olmalıdır.
  </Accordion>
</AccordionGroup>

***

## Seçenek B — OAuth 2.0 hizmet uygulaması

Güvenlik politikanız uzun ömürlü API belirteçlerine izin vermiyorsa bu yöntemi kullanın. Belirteç yerine bir istemci kimliği ve size ait bir RSA anahtar çifti kullanılır. Platformda bu, **Ayarları → Entegrasyonları → Kataloğu** altındaki **Okta (OAuth 2.0)** kutucuğudur.

Client Credentials kullanarak Okta ile kimlik doğrulaması yapmak için aşağıdakilere ihtiyacınız vardır:

1. **İstemci Kimliği** - Okta API Services uygulamanız için benzersiz bir tanımlayıcı.
2. **Private Key (JWK)** - JSON Web Key biçimindeki RSA özel anahtarı; genel anahtarı Okta uygulamanıza kayıtlıdır.
3. **Okta Domain** - Yalnızca Okta tenant alt alan adınız (ör. `dev-12345678`), tam ana bilgisayar adı değil.
4. **Scopes** - Boşlukla ayrılmış Okta Management API kapsamları listesi (ör. `okta.users.read okta.logs.read`).

Bu kılavuz, `private_key_jwt` kimlik doğrulaması ile Okta'da bir API Services uygulaması oluşturma adımlarında size yol gösterecektir.

### Ön koşullar:

* Bir Okta hesabınızın olması gerekir. [developer.okta.com](https://developer.okta.com/signup/) adresinden ücretsiz bir geliştirici hesabı için kaydolabilirsiniz.

#### Adım 1: Okta API Services uygulamanızı oluşturma

1. [Okta Admin Console](https://login.okta.com/) oturumunuzu açın.
2. Sol kenar çubuğunda **Applications** > **Applications** yolunu izleyin.
3. **Create App Integration** öğesine tıklayın.
4. Oturum açma yöntemi olarak **API Services** öğesini seçin ve **Next** öğesine tıklayın.

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

5. Uygulamanıza bir ad verin ve **Save** öğesine tıklayın.
6. Uygulamanın **General** sekmesinde **Client ID** değerinizi bulun; son adımda bu değere ihtiyacınız olacak.
7. Client authentication ayarını **Public key / Private key** olarak belirleyin. `okta.*` kapsamları yalnızca bu kimlik doğrulama yöntemiyle desteklenir.

<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)** seçeneğini devre dışı bırakın; desteklenmemektedir.

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

<Note>
  Uygulama **API Services** olarak oluşturulmalıdır.
</Note>

#### Adım 2: RSA anahtar çiftinizi oluşturma ve kaydetme

##### Okta anahtar oluşturucusunu kullanın

Okta, RSA anahtar çiftini doğrudan Admin Console'da sizin için oluşturabilir:

1. Admin Console'da API Services uygulamanızı açın.
2. **General** sekmesine gidin ve **PUBLIC KEYS** bölümüne kadar kaydırın.
3. **Add Key** öğesine tıklayın, ardından **Generate new key** öğesini seçin.
4. **Save** öğesine tıklayın; Okta anahtar çiftini oluşturur ve **Private Key (JWK)** değerini yalnızca bir kez görüntüler.
5. Özel anahtar JSON'unu hemen kopyalayıp kaydedin; bir daha gösterilmeyecektir.

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

6. Genel anahtar, uygulamanıza otomatik olarak kaydedilir.

<Note>
  İletişim kutusunu kapatmadan önce özel JWK'yi kopyalayın. Son adımda bunu Living Security Platform'daki **Private Key** alanına yapıştırın.
</Note>

##### Kendi anahtarınızı oluşturun

Okta, API Services uygulamaları için `private_key_jwt` kullanır. Bir RSA anahtar çifti oluşturur, **genel** JWK'yi Okta'ya kaydeder ve **özel** JWK'yi Living Security Platform'a sağlarsınız.

Aşağıdaki Node.js betiğini kullanarak **özel bir JWK oluşturun** (Node.js 18+ gerektirir):

```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));
```

**Genel JWK'yi Okta'ya kaydedin:**

1. Admin Console'da API Services uygulamanızı açın.
2. **General** sekmesine gidin ve **PUBLIC KEYS** bölümüne kadar kaydırın.
3. **Add Key** öğesine tıklayın, yukarıdaki betiğin çıktısı olan **genel JWK JSON**'unu yapıştırın ve **Save** öğesine tıklayın.

<Note>
  Living Security Platform'a yapıştıracağınız şey özel JWK'dir. Tüm anahtar materyalini (`d`, `p`, `q`, `dp`, `dq`, `qi`) ve `kid` değerini içerir. Gizli tutun.
</Note>

#### Adım 3: Okta Domain değerinizi bulma

Yalnızca Okta tenant alt alan adınızı girin; yani `.okta.com` öncesindeki kısmı.

* Admin Console'da tarayıcınızın adres çubuğunda `https://dev-12345678-admin.okta.com` gibi bir URL görünür.
* **Okta Domain** değeriniz yalnızca alt alan adıdır (ör. `dev-12345678`), `dev-12345678.okta.com` değildir.
* Alternatif olarak, Okta alan adınızı bulmak için Admin Console'da **Settings** > **Account** yolunu izleyin, ardından alt alan adı kısmını kullanın.

#### Adım 4: Uygulamanıza API kapsamları verme

Okta, her belirteç isteğinde en az bir kapsam gerektirir. Uygulamanız belirli kapsamları isteyebilmeden önce bu kapsamların verilmiş olması gerekir:

1. Admin Console'da **Applications** > **Applications** yolunu izleyin ve uygulamanızı açın.
2. **Okta API Scopes** sekmesine tıklayın.
3. Entegrasyonunuzun gerektirdiği kapsamları verin: `okta.users.read` ve `okta.logs.read`.

Kullanılabilir kapsamların tam listesi [Okta Management API başvurusunda](https://developer.okta.com/docs/api/oauth2/#okta-admin-management) yer almaktadır.

#### Adım 5: Uygulamanıza bir yönetici rolü atama

Yalnızca kapsam vermek yeterli değildir; uygulamanızın yönetici rolü yoksa Okta Management API uç noktaları (ör. `/api/v1/users`) sessizce boş bir `200 []` yanıtı döndürür. En az **Read-Only Administrator** rolünü atamanız gerekir:

1. Admin Console'da **Security** > **Administrators** yolunu izleyin (veya **Applications** > **Applications** > uygulamanız > **Admin roles** yolunu izleyin).
2. **Add administrator assignment** öğesine tıklayın ve API Services uygulamanızı seçin.

<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** rolünü (veya ihtiyaç duyduğunuz kapsamlara bağlı olarak daha yüksek bir rolü) atayın.
4. **Save** öğesine tıklayın.

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

<Note>
  Yönetici rolü olmadan API çağrıları `200 OK` ile başarılı olur ancak boş sonuçlar döndürür ve sorunu gösteren bir `403` hatası yoktur.
</Note>

#### Adım 6: Kimlik bilgilerini Living Security Platform'a girme

**İstemci Kimliği**, **Private Key (JWK)**, **Okta Domain** ve **Scopes** değerlerinize sahip olduğunuzda:

1. Okta ile (Client Credentials) kimlik doğrulaması yapmanız gereken formu açın.
2. **İstemci Kimliği** değerinizi girin.
3. **Private Key (JWK)** değerinizi yapıştırın; yani yukarıdaki betikten elde edilen JSON nesnesinin tamamını (tek satır veya biçimlendirilmiş).
4. **Okta Domain** değerinizi yalnızca tenant alt alan adı olarak girin (ör. `dev-12345678`).
5. **Scopes** değerlerini boşlukla ayrılmış bir liste olarak girin (ör. `okta.users.read okta.logs.read`).
6. Formu gönderin; kimlik doğrulaması başarıyla tamamlanmış olmalıdır.

Artık Okta (Client Credentials) ile bağlantı kurdunuz.

***

<Note>Bu belgelerin bazı bölümleri [Nango](https://nango.dev/docs/) kaynağından uyarlanmıştır ve [Elastic License 2.0](https://github.com/NangoHQ/nango?tab=License-1-ov-file#readme) kapsamında kullanılmaktadır.</Note>

<PublicIntegrationNextSteps />


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