Kimlik doğrulamaya genel bakış

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: 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 sayfasına bakın. 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 sayfasına bakın.

​

Desteklenen akışlar

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 sayfasına bakın. 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 sayfasına bakın.

​

Desteklenmeyen akışlar

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.

​

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 sayfasında anlatılır.

​

Token türleri

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