> ## Documentation Index > Fetch the complete documentation index at: https://docs.flextell.ai/llms.txt > Use this file to discover all available pages before exploring further. # Kimlik doğrulamaya genel bakış > OAuth 2.0 ve OpenID Connect ile kullanıcı adına erişim modelini, desteklenen akışları ve izin ile scope'un birlikte nasıl çalıştığını açıklar. Flextell API'si OAuth 2.0 ve OpenID Connect kullanır. Uygulamanız bir Flextell kullanıcısından izin alır ve o kullanıcı adına `access token` ile istek yapar. Bu sayfa modelin tamamını özetler; her adımın ayrıntısı için ilgili sayfalara bağlantı verilmiştir. ## Erişim modeli API'ye erişim her zaman bir kullanıcı adına yapılır. Uygulamanın kendi başına, kullanıcısız çalışan bir erişimi yoktur. Bir isteğin kabul edilmesi için üç şey gerekir: | Bileşen | Nerede gönderilir | Ne belirler | | - | - | - | | `access token` | `Authorization: Bearer ` | Kullanıcının kim olduğunu ve uygulamanın hangi scope'lara sahip olduğunu | | Klinik | `X-Tenant: ` | İsteğin hangi klinikte yapıldığını | | Kullanıcının rolü | Gönderilmez; sunucu klinikteki role bakar | Kullanıcının o klinikte hangi işlemleri yapabildiğini | Kimlik doğrulama ayrı bir kimlik sunucusunda yapılır: üretimde `https://id.flextell.ai`, sandbox'ta `https://iddev.flextell.ai`. Kullanıcı giriş yapar, gerekirse iki adımlı doğrulamayı geçer ve uygulamanıza izin verir. İş verisine ise API adresinden (`https://app.flextell.ai/api/v1`) erişirsiniz. Ortam adresleri için [Ortamlar](/api/ortamlar) sayfasına bakın. ```mermaid theme={null} flowchart LR A[Uygulamanız] -->|1. Yetkilendirme isteği| B[Kimlik sunucusu] B -->|2. Kullanıcı girişi ve izin| B B -->|3. Kod, sonra token| A A -->|4. Bearer token + X-Tenant| C[Flextell API] ``` Kullanıcı birden fazla kliniğin üyesi olabilir. Klinik değiştirmek için yeni token almanız gerekmez; aynı token kullanıcının her kliniğinde çalışır ve yalnızca `X-Tenant` değeri değişir. Ayrıntılar için [Klinikler ve X-Tenant](/api/klinikler-ve-x-tenant) sayfasına bakın. ## Desteklenen akışlar | Akış | Ne zaman kullanılır | API'de kullanılabilir mi | | - | - | - | | Yetkilendirme kodu (`authorization_code`) + PKCE | Kullanıcı adına ilk token'ı almak için | Evet | | Yenileme (`refresh_token`) | Süresi dolan `access token`'ı yenilemek için | Evet | Yetkilendirme kodu akışında uygulamanız kullanıcıyı `/oauth/authorize` adresine yönlendirir. Kullanıcı girişten ve izin ekranından geçince uygulamanıza tek kullanımlık bir kod döner. Siz bu kodu `/oauth/token` adresinde token ile değiştirirsiniz. Adım adım anlatım için [Yetkilendirme kodu ve PKCE](/api/kimlik-dogrulama/yetkilendirme-kodu-ve-pkce) sayfasına bakın. PKCE'de `code_challenge_method` belirtilmezse `plain` kullanılır. Yöntem olarak her zaman `S256` gönderin. Uygulamanın istemci türü PKCE kuralını belirler: * Gizli anahtarı (`client_secret`) olmayan, herkese açık istemciler için PKCE zorunludur. * Gizli istemcilerde PKCE isteğe bağlıdır. Ancak `code_challenge` gönderdiyseniz token isteğinde `code_verifier` göndermek zorundasınız. * Gizli istemciler token adresinde `client_secret` ile kimliğini doğrular. Eksik gizli anahtar `400 invalid_request`, yanlış gizli anahtar `401 invalid_client` döndürür. OpenID Connect kullanmak için istekteki `scope` değerine `openid` ekleyin. Bu durumda token yanıtında `id_token` da gelir. `openid`, `profile`, `email` ve `phone` kimlik scope'larıdır; uygulamanın scope listesinden bağımsız olarak her uygulama için geçerlidir. Ayrıntılar için [OpenID Connect](/api/kimlik-dogrulama/openid-connect) sayfasına bakın. ## Desteklenmeyen akışlar | Akış | Sonuç | | - | - | | `password` (kullanıcı adı ve parola ile token alma) | `400 unsupported_grant_type` | | Örtük akış (`response_type=token`) | `400 unsupported_grant_type` | | `client_credentials` | Token verilebilir, ancak API'de çalışmaz | `client_credentials` ile alınan token bir kullanıcıya bağlı değildir. Bu yüzden `/api/v1` altındaki her istek `401 UNAUTHENTICATED` döndürür. Uygulama oluştururken de bu akış varsayılan olarak açılmaz: API üzerinden oluşturulan uygulamalar yalnızca `authorization_code` ve `refresh_token` akışlarına sahiptir. Kullanıcı parolasını uygulamanızda toplayıp token almaya çalışmayın. Giriş her zaman kimlik sunucusunun kendi sayfasında yapılır. ## Scope ve izin Bir isteğin başarılı olması için iki ayrı koşul birlikte sağlanmalıdır. Biri yetersizse istek reddedilir. 1. **Scope:** Uygulamanın, kullanıcının izniyle aldığı token'da o endpoint için gereken scope bulunmalıdır. Örneğin hasta listesi için `customers:read`. Eksikse `403 FORBIDDEN` ve `Invalid scope(s) provided.` mesajı döner. 2. **İzin:** Kullanıcının, `X-Tenant` ile seçilen klinikte o işlem için rolünden gelen izni olmalıdır. Örneğin `View:Customer`. Eksikse `403` ve `Bu işlem için yetkiniz yok.` mesajı döner. Scope uygulamanın ne yapabileceğini, izin ise kullanıcının ne yapabileceğini sınırlar. Etkin yetki ikisinin kesişimidir. Kullanıcıda izin olsa bile uygulama scope almadıysa işlem yapılamaz; uygulama scope aldıysa bile kullanıcıda izin yoksa işlem yapılamaz. İki kontrolden sonra görünürlük kuralları da devreye girer. `View` izni olan ama `ViewAll` izni olmayan bir kullanıcı, örneğin yalnızca kendisine atanmış kayıtları görür. Bu kurallar [İzinler ve görünürlük](/api/izinler-ve-gorunurluk) sayfasında anlatılır. Scope'lar uygulama oluşturulurken seçilir ve kullanıcı izin ekranında bunları onaylar. Yenileme sırasında scope'lar yalnızca daraltılabilir; yeni scope için kullanıcıyı yeniden yetkilendirmeye göndermeniz gerekir. Tüm scope listesi için [Scope'lar](/api/kimlik-dogrulama/scopelar) sayfasına bakın. ## Token türleri | Token | Süre (üretim) | Ne için kullanılır | | - | - | - | | `access_token` | 5 dakika | API isteklerinde `Authorization: Bearer` başlığıyla gönderilir | | `refresh_token` | 7 gün | Yeni `access_token` almak için `/oauth/token` adresine gönderilir | | `id_token` | 1 saat | Yalnızca `openid` scope'u istendiyse gelir; kullanıcının kimliğini taşır ve oturum kapatmada `id_token_hint` olarak kullanılır | Yetkilendirme kodunun kendisi de 10 dakika geçerlidir ve yalnızca bir kez kullanılabilir. Sandbox'ta token süreleri üretimden farklı olabilir; süreleri sabit varsaymayın, `expires_in` alanını okuyun. Yenileme sırasında şu kurallar geçerlidir: * Her yenileme **yeni bir `refresh_token`** döndürür. Kullanılan eski `refresh_token` ve onunla eşleşen `access_token` hemen geçersiz olur. * Yeni `refresh_token`'ı hemen saklayın. Eski olanı tekrar gönderirseniz `400 invalid_grant` alırsınız. * İsteğe bağlı `scope` parametresi, ilk yetkilendirmede verilen scope'ların alt kümesi olmalıdır. Aksi hâlde `400 invalid_scope` döner. * Uygulamanız haftada en az bir kez yenileme yaparsa kullanıcı yeniden giriş yapmak zorunda kalmaz. Her yenileme 7 günlük yeni bir `refresh_token` verir. `access_token` 5 dakikada dolduğu için uygulamanız `401 UNAUTHENTICATED` yanıtını yakalayıp token'ı yenilemeli ve isteği tekrar etmelidir. ## İlgili sayfalar Client ID ve Client Secret alın, scope seçin. Kullanıcıyı yönlendirin ve kodu token ile değiştirin. Token yenileme ve iptal. OAuth ve OpenID Connect hata kodları. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.