Identity Manager

OIDC, OAuth 2.0, JWT, JOSE — her API ve agent için tek kimlik yüzeyi.

Zaten işlettiğiniz dizinle federasyon kurun, her standart token'ı uçta doğrulayın ve kimin neyi çağırabileceğini yönetin — hepsi Manager arayüzünden. Aynı kimlik politikası API ve AI trafiğini birlikte denetler; üç katmanlı yetkiler ve her değişiklikte Repository katmanında denetimle.

  • StandartlarOIDC · OAuth 2.0 · JWT · JOSE · SAML · mTLS
  • FederasyonLDAP · AD · OIDC · REST · Database
  • KatmanlarSistem · Proje · Takım

01 · Kimlik doğrulama standartları

Dokuz standart. Tek politika yüzeyi.

Modern OAuth 2.0, OIDC, JWT ve JOSE'nin yanında, eski sistemlerinizde hâlâ yaşayan mTLS, SAML, Basic, Digest ve Base64 akışları. Her yöntem, yazmanız gereken bir eklenti değil, arayüzü olan birinci sınıf bir politikadır — ve aynı politika denetimi hem API hem AI trafiğinin önünde çalışır.

  • OAuth 2.0 — Authorization Code (PKCE ile), Client Credentials, ROPC, Refresh Token
  • OIDC — discovery URL, ID token + access token, JWKS, hibrit External + Internal modu
  • JWT — üretme, doğrulama, RS256 / RS384 / RS512 ile imzalama, dönen JWKS ile üçüncü taraf JWT
  • JOSE — claim'ler için JWS imzalama + JWE şifreleme, uçta dinamik anahtar çekme
  • Hâlâ ihtiyaç duyan her eski iş ortağı için mTLS, SAML 2.0, HTTP Basic, Digest, Base64
  • policy-oidc
  • policy-oauth-2-auth
  • policy-jwt-auth
  • policy-jose-implementation
  • policy-jose-validation
  • policy-mtls-authentication
  • policy-saml
  • basic-auth
  • digest-auth

AI için aynı şerit

AI Gateway istekleri aynı kimlik bilgisini taşır — her LLM çağrısı, paylaşılan bir API anahtarıyla değil, çağırana zaten verilmiş OAuth veya OIDC token'ıyla doğrulanır.

Authentication standards panel — OIDC selected, with discovery URL, client ID, scopes, and a row of nine supported method tabs underneath.

02 · OIDC + OAuth 2.0

OpenID Connect ve PKCE'li gerçek Authorization Code — kutudan çıktığı gibi.

OIDC politikası, tüm yüzeyi tek bir Mongo koleksiyonunda toplar: Discovery URL veya endpoint bazlı yapılandırma, JWKS destekli imza doğrulama, ID token + access token doğrulaması, hibrit mod (harici IdP + dahili kimlik bilgileri), nonce + state ile replay koruması ve claim'lerden rol eşleme. Apinizer; Keycloak, Azure AD, Okta veya kurum içi IdP'nizle aynı formu kullanarak konuşur.

  • Varsayılan olarak PKCE etkin Authorization Code Flow — public client'ları korur
  • Discovery URL; issuer, authorize, token, userinfo ve JWKS endpoint'lerini otomatik doldurur
  • JWKS destekli imza doğrulama — RS256, RS384, RS512, ES256, ES384, ES512, PS256, EdDSA
  • iss / aud / exp / nonce / state kontrolleri ve saat kayması toleransıyla ID token + access token doğrulaması
  • Hibrit mod — kullanıcı kimliği için harici IdP, API yetkilendirmesi için Apinizer kimlik bilgileri
  • Kullanıcı adı, e-posta, görünen ad ve roller için claim eşleme — doğrudan istek bağlamına
  • Dağıtık önbellek destekli oturum — `OIDC_SESSION` çerezi Worker yeniden başlatmalarını atlatır
  • `id_token_hint` ve çıkış sonrası yönlendirme destekli logout endpoint'i
  • PKCE
  • Discovery URL
  • JWKS
  • RS256 · ES256 · PS256 · EdDSA
  • hybrid mode
  • nonce + state
  • role mapping
  • distributed session
OIDC + OAuth 2.0 flow — browser to identity provider, Apinizer validates the ID token via JWKS, role claims map to Apinizer scopes, the request is forwarded with a hybrid token.

03 · JWT kimlik doğrulama

JWT — Apinizer tarafından üretilir ya da herhangi bir üçüncü taraf issuer'a karşı doğrulanır.

Apinizer kendi JWT'lerini üretebilir (RS256 / RS384 / RS512, ortama bağlı JwtKey2048) ya da başka bir platformun ürettiği token'ları — dönen JWKS ve kimlik bilgisi başına refresh token'larla — doğrulayabilir. Özel eşlemeler dahil token claim'leri, üstteki servisler token'ı yeniden çözmek zorunda kalmasın diye istek bağlamına header olarak iletilir (`X-Authenticated-UserId`, `X-Authenticated-UserRoles`).

  • RS256, RS384, RS512 ile JWT üretimi — anahtarlar ortam kapsamlı Secret Manager'da tutulur
  • Üçüncü taraf JWT doğrulama (`jwt-3rd-party-auth`) — dönen JWKS, politika başına birden çok issuer
  • Grant türleri: Password, Client Credentials, Refresh Token — yenileme sayısı ve TTL yapılandırılabilir
  • Kimlik bilgisi veya politika başına token süresi — saniye, dakika, saat cinsinden yapılandırılabilir
  • Claim'den header'a eşleme — `sub`, `email`, `roles` ve dilediğiniz özel claim
  • Politika başına değişken çözümleme — yalnızca `getResolvedXxx()`, asla ham alanlar, istekler arası sızıntı yok
  • Eski çağıranlar için isteğe bağlı URL parametreli token'lar — yine denetlenir ve hız limitine tabidir
  • RS256
  • RS384
  • RS512
  • rotating JWKS
  • refresh tokens
  • claims-to-header
  • third-party JWT
Decoded JWT view — header showing alg RS256 and kid, payload with iss, sub, aud, exp, scope, roles, and a signature panel highlighting the JWKS endpoint that validated it.

04 · JOSE — JWS + JWE

Claim'leri JOSE ile imzalayın ve şifreleyin — el yapımı bir sarmalayıcıyla değil, standardın kendisiyle.

Bir isteğin gövdesinin imzalı ya da şifreli bir JWT olması gerektiğinde — bankacılık iş ortakları, regülasyona tabi payload'lar, B2B el sıkışmaları — Apinizer'ın JOSE Implementation politikası herhangi bir alanı, header'ı veya gövdeyi doğru `iss`, `aud`, `exp`, `iat`, `jti`, `sub` claim'leri ve seçilen bir JWK ile JWS / JWE'ye dönüştürür. JOSE Validation politikası gelen trafikte bunun tersini yapar. Anahtarlar Secret Manager'dan alınır — ya da önbelleklenmiş, dönen bir çekimle uzak bir endpoint'ten canlı olarak çekilir.

  • JOSE Implementation — istek gövdesini, header'ları veya herhangi bir değişkeni imzalar (JWS) ve / veya şifreler (JWE)
  • JOSE Validation — imzayı doğrular, şifreyi çözer ve claim'leri istek bağlamına geri yansıtır
  • Standart JWT claim'leri — offset'li `iat`, `iss`, `aud` listesi, `sub`, `jti`, üretim anından veya şu andan itibaren `exp`
  • Özel claim haritası — istek değişkenlerinden eklenen ilave alanlar
  • Dinamik anahtar çekme — iş ortağı endpoint'inden JWK alın, önbelleğe koyun (TTL, kapasite, mTLS, yeniden deneme)
  • JWK formatları — RSA, EC, OKP, oct — `kid`, `x5t`, `x5c` parmak izi doğrulamasıyla
  • Algoritmalar — RS256/384/512, ES256/384/512, PS256/384/512, EdDSA ve paylaşılan gizli anahtar kullanan iş ortakları için HS ailesi
  • Issuer'a göre imzalama — JWK'yı çalışma anında çözümlenen issuer claim'inden seçin, sabit kodlanmış anahtar kimliği yok
  • policy-jose-implementation
  • policy-jose-validation
  • JWS
  • JWE
  • dynamic JWKS
  • kid · x5t · x5c
  • RSA · EC · OKP
  • sign-by-issuer

AI için aynı şerit

Aynı JOSE politikası, harici bir LLM'e gönderilen prompt'u da imzalayabilir — iş ortağınız isteğin çalınmış bir API anahtarından değil, gerçekten sizin gateway'inizden geldiğini doğrular.

JOSE policy editor — sign + encrypt toggles on, claims list with iss, aud, exp, jti, sub, and a dynamic key panel pulling a JWK from a remote URL with TTL 3600 seconds.

05 · Dizin federasyonu

Zaten işlettiğiniz dizinle federasyon kurun.

LDAP, Active Directory, SAML 2.0, harici bir REST IdP veya bir veritabanı tablosu — Apinizer bunların hepsine karşı, özel bir entegrasyonla değil, bir yapılandırma formuyla kimlik doğrular. Grup üyelikleri ilk oturum açmada Apinizer rollerine eşlenir; böylece mevcut organizasyon şemanız, paralel bir kullanıcı deposu olmadan erişimi yönetir.

  • LDAP / Active Directory — bind, arama filtresi, grup eşleme, gelişmiş yapılandırma (referral, sayfalama, TLS)
  • SAML 2.0 servis sağlayıcı — assertion doğrulamalı, IdP ve SP tarafından başlatılan SSO
  • REST üzerinden özel IdP — `AuthenticationApi` endpoint'inizi çağırır, yanıtı eşler, sonucu önbelleğe alır
  • Veritabanı destekli — MySQL, PostgreSQL, Oracle, MSSQL üzerinde parametreli sorgularla kimlik doğrulama
  • Aynı OIDC politikası üzerinden harici IdP federasyonu — Keycloak, Azure AD, Okta, Auth0
  • İlk oturum açmada otomatik sağlama — operatör, talep açmadan Proje üyesi olur
  • Dört backend'in tümü, bir JWT veya OAuth 2.0 grant'inin arkasında parola doğrulayıcı olarak kullanılabilir
  • AuthenticationLDAP
  • AuthenticationDatabase
  • AuthenticationApi
  • policy-saml
  • Keycloak
  • Azure AD
  • Okta
Federation panel — five source cards: LDAP/AD, SAML 2.0, OIDC external, Custom REST, Database — each with a green status dot and a 'group → role' mapping arrow.

06 · Kimlik bilgileri ve API anahtarları

Rotasyon, ACL ve şifreleme yerleşik gelen kimlik bilgileri.

Her tüketici — insan, uygulama veya agent — `@SecretData` parolası, verilmiş bir API anahtarı, izinli proxy'ler ve metotlar, kimlik bilgisi başına hız limitleri, IP grupları, coğrafi kısıtlar ve gün içi zaman pencereleriyle bir `Credential`dır. Rotasyon, Worker'ın önbellek üzerinden devraldığı bir Manager işlemidir — uçuştaki çağrıları kesintiye uğratmaz.

  • API anahtarlarını Manager arayüzünden veya APIops'tan üretin, doğrulayın, döndürün, iptal edin
  • @SecretData ile beklemede şifreleme — parolalar ve gizli anahtarlar asla düz metin olarak saklanmaz
  • Kimlik bilgisi başına hız limitleri, kotalar ve burst pencereleri — API düzeyindeki limitlerden bağımsız
  • İzinli ve yasaklı API proxy'leri, endpoint düzeyinde ACL'ler, metot düzeyinde kısıtlar
  • Kimlik bilgisine bağlı IP izin listeleri ve coğrafi konum verisi
  • Zaman kısıtlı erişim — yalnızca belirli saatlerde çalışan iş ortağı sözleşmeleri
  • Worker önbelleğiyle koordineli rotasyon akışı — uçuştaki çağrılar temiz biçimde tamamlanır
  • API Portal üzerinden self servis — uygulamalar talep açmadan anahtar ister, onaylar ve döndürür
  • @SecretData
  • API key rotation
  • per-credential RL
  • endpoint ACL
  • IP groups
  • geo restrictions
  • time-of-day
Credential list — three rows showing app name, key prefix, allowed proxies, rate limit, IP group, and a 'Rotate' action button on the active row.

07 · Üç katmanlı yetki modeli

Sistem · Proje · Takım — her kontrol, aynı servis.

Tek bir `PermissionService`, her okuma, yazma ve deploy işleminde üç katmanlı erişimi uygular — UI, REST, AI Gateway, APIops. Sistem yöneticileri her şeyi görür; Proje sahipleri yalnızca sahip olduklarını; Takım üyeleri yalnızca kendilerine tanınan dilimi. Özel roller, gateway'e veya denetim hattına dokunmadan daha dar kapsamlar eklemenizi sağlar.

  • Üç kapsam — Sistem, Proje, Takım — her varlığa uygulanır (proxy, kimlik bilgisi, gizli anahtar, politika)
  • RBAC ile özel roller — bir kez tanımlayın, istediğiniz yere bağlayın
  • Servis ve Repository katmanında yetki kontrolleri — UI bunları atlayamaz
  • Aynı `PermissionService`; UI işlemlerini, REST API çağrılarını ve APIops apply'larını denetler
  • Proje kapsamlı secret manager — anahtarlar, sertifikalar, JWK'lar yalnızca sahibi olan Proje'ye görünür
  • Takım üyeliği; Manager arayüz görünürlüğünü ve AI Gateway istek yetkilendirmesini belirler
  • Yetki reddi, eksik kapsamı tam olarak belirten yapılandırılmış bir 403 döndürür — hata ayıklaması kolay
  • PermissionService
  • System / Project / Team
  • custom roles
  • RBAC
  • Repository-layer enforcement
Permission matrix — three columns System, Project, Team; rows for read proxy, deploy proxy, manage credentials, rotate keys; checks on the cells, denied marks where appropriate.

08 · Denetim ve izlenebilirlik

Her kimlik doğrulama, her değişiklik — Repository katmanında kayıt altında.

Kimlik doğrulama sonuçları (başarı, ret, kısıtlama, engelleme) istek trafiğiyle aynı Elasticsearch analitik deposuna akar. Manager tarafındaki değişiklikler — kimlik bilgileri, politikalar, ACL'ler, rol eşlemeleri — Repository katmanındaki bir denetim aspect'i tarafından yakalanır; böylece 'anahtarı kim verdi, kim döndürdü, kapsamı kim tanıdı' sorusu güvenlik ekibi için asla açık kalmaz.

  • Kimlik doğrulama denemeleri Elasticsearch'te indekslenir (`analytic-auth-record`) — başarı, ret, gerekçe
  • Repository katmanı denetim aspect'i — her kayıt / güncelleme / silme; kullanıcı, zaman damgası ve diff ile loglanır
  • Kimlik bilgisi ve politika değişiklikleri, operatörün kimliğini uçtan uca taşır (UI → REST → DB)
  • Diff yakalama — eski değer, yeni değer; `@SecretData` alanları maskelenir
  • APIops apply'ları aynı denetim akışında görünür — gölge değişiklik yolu yok
  • Manager arayüzünde gerçek zamanlı izleme, Elasticsearch'te uzun süreli saklama
  • Başarısız kimlik doğrulama eğilimleri ve brute-force tespiti, trafikle aynı panoda durur
  • analytic-auth-record
  • Elasticsearch
  • Repository audit aspect
  • @SecretData masking
  • diff capture
  • APIops parity

AI için aynı şerit

Aynı denetim hattı her AI Gateway kimlik doğrulamasını da kaydeder — kimlik bilgisi başına token harcaması, reddedilen prompt'lar ve rotasyon olayları tek bir logda.

Audit timeline — five events: credential created, ACL added, key rotated, policy updated, deny on bad token; each entry shows actor, scope, and a diff arrow.

Pakete dahil

Neler dahil

Aşağıdaki yetenekler standart kurulumun parçasıdır — ek SKU'lar ve ayrı lisanslar yoktur.

Kimlik doğrulama

  • OIDC — PKCE'li Authorization Code, ID + access token, hibrit mod
  • OAuth 2.0 — Authorization Code, Client Credentials, ROPC, Refresh Token
  • JWT — üretme + doğrulama, RS256/384/512, üçüncü taraf JWKS, refresh token'lar
  • JOSE — JWS imzalama + JWE şifreleme, dinamik anahtar çekme, kid / x5t / x5c
  • mTLS, SAML 2.0, HTTP Basic, Digest, Base64
  • LDAP / AD federasyonu, özel REST IdP, veritabanı destekli

Yetkilendirme ve yönetişim

  • Üç katmanlı yetki modeli (Sistem / Proje / Takım)
  • Özel roller + RBAC — UI, REST, APIops, AI Gateway genelinde uygulanır
  • API Proxy / endpoint / metot başına ACL'ler
  • API anahtarı üretme, doğrulama, rotasyon, iptal
  • Kimlik bilgisi başına hız limitleri, kotalar, IP grupları, coğrafi kısıtlar
  • İş ortağı sözleşmeleri için gün içi erişim pencereleri
  • Diff yakalama ve `@SecretData` maskelemeli Repository katmanı denetim aspect'i

Tek kimlik yüzeyi

Her sistem için ayrı bir kimlik katmanı işletmeyi bırakın.

OIDC, OAuth 2.0, JWT ve JOSE'yi mevcut LDAP ve SAML'ınızla aynı gateway üzerinde çalışırken görün — ve her kimlik bilgisi rotasyonunun arkasındaki aynı denetim izini.