Türkçe
  • api-keys
  • personal-access-tokens
  • machine-to-machine
  • service-to-service
  • backend-to-backend
  • authentication
  • authorization
  • security
  • jwt
  • oauth2
  • rbac

Programatik kimlik doğrulama: API anahtarı, kişisel erişim belirteci ve OAuth istemci kimlik bilgileri akışı

API anahtarı, Kişisel Erişim Belirteci (PAT) ve Logto Makineden Makineye (M2M) kimlik bilgileri için anahtar kavramları ve yaygın kullanım durumlarını keşfedin.

Charles
Charles
Developer

Arka Plan

Yazılım geliştirmede, CLI komutları aracılığıyla API kaynağına programatik olarak erişmemiz gerektiğinde veya arka uç hizmetler arasında iletişim kurmamız gerektiğinde, biz geliştiriciler tarafından yaygın olarak kullanılan üç kimlik doğrulama mekanizması bulunur: API anahtarı, Kişisel Erişim Belirteci (PAT) ve OAuth istemci kimlik bilgileri akışı (Logto'da Makineden Makineye olarak markalanmıştır). Peki bunlar arasındaki farklar nelerdir? Bu yöntemlerin her biri için en iyi uyum senaryosu nedir? Bu blog yazısında, benzerlikleri, farklılıkları inceleyecek ve farklı senaryolarda hangi yöntemin ne zaman kullanılacağı hakkında bilgiler vereceğiz.

Tanımlar

  • API anahtarı: Bir API kaynağına isteğinizi kimlik doğrulayan basit bir dizi.
  • Kişisel Erişim Belirteci (PAT): Aynı zamanda basit bir dizi ama bir API kaynağına kimlik doğrulamak için kullanıldığında bir kullanıcıyı temsil eder. Bu, bir kullanıcının yetki devridir.
  • Logto Makineden Makineye (Logto M2M): Önceden kayıtlı bir istemci gerektiren ve bir erişim belirteci ile takas etmek için istemci kimliği ve gizli anahtarı kullanmayı gerektiren standart OAuth istemci kimlik bilgileri akışı. Böylece, Logto M2M kimlik bilgisi güvenilir bir istemciyi temsil eder ve OAuth istemci kimlik bilgileri akışının doğası gereği kullanımı nispeten karmaşıktır.

Benzerlikler

1. Kimlik doğrulama amacı

  • Üçü de, API anahtarı, PAT ve Logto M2M, bir kullanıcıyı veya uygulamayı belirli bir hizmet veya kaynağa erişmek için kimlik doğrulama amacıyla hizmet ederler. İstekçinin kimliğini kanıtlamak için kimlik bilgileri olarak hareket eder ve genellikle CLI komutlarında veya arka uçtan arka uca iletişim senaryolarında kullanılırlar.

2. Güvenlik önlemleri

  • Bu üç kimlik doğrulama yöntemi de güvenlik göz önünde bulundurularak ele alınmalıdır. Geliştiriciler, yetkisiz erişimi önlemek için güvenli depolama ve iletimi sağlamalıdır.

Farklılıklar

1. Kullanıcı bağlamı

  • API anahtarı bir asıl tanımlamaz, ayrıca hiçbir yetkilendirme bilgisi de sağlamaz. Bu nedenle, API anahtarları genellikle bir kullanıcı olmadan anonim olarak genel veri veya kaynaklara erişim sağlamak için kullanılır. Tüm hizmetler API anahtarlarının kullanılmasını desteklemez.
  • PAT kullanıcı kimlikleri olup bir API kaynağına istek yaptığında sizi temsil eder. Bazı sistemlerde, PAT'lerin belirli hizmetlere erişmesine izin verilmez. Örneğin, NuGet paketlerinin Azure Artifacts beslemesine yayınlanması.
  • Logto M2M kimlik bilgileri yalnızca güvenilir istemciler tarafından kullanılabilir. İstemci kimlik doğrulama için önceden kayıtlı olmalıdır. Logto M2M kimlik bilgilerini kullanırken, onu kullanan kullanıcıyı değil, güvenilir istemciyi temsil eder.

2. İzinlerin detaylandırılması

  • PAT ve Logto M2M kimlik bilgileri genellikle API anahtarına kıyasla izinler üzerinde daha ayrıntılı kontrol sunar, hangi eylemlerin gerçekleştirilebileceği konusunda ince kontrollere izin verir.

3. Belirteç formatı

  • API anahtarı ve PAT genellikle opak türde dizelerdir, basit ve sadedir.
  • Logto M2M mekanizması aracılığıyla verilen erişim belirteçleri genellikle JWT formatında olur.

4. Yetkilendirme akışı

  • API anahtarı ve PAT sistem tarafından oluşturulan opak dizelerdir, işlem sırasında herhangi bir kimlik doğrulama akışı içermezler. Örneğin, Google Cloud doğal dil API'sını şu şekilde çağırabilirsiniz:
  • Logto M2M, standart OAuth 2.0 istemci kimlik bilgileri akışını kullanır. Her istemci, önceden bir çift istemci kimliği ve istemci sırrı edinmeli ve bu kimlik bilgileri ile daha sonra bir erişim belirteci almak için değiş tokuş yapılabilir. Ardından istemci, API kaynağına erişmek için erişim belirtecini kullanır.

Hangi durumda hangi yöntemi kullanmalı

API anahtarı

  • Hizmetten hizmete iletişim: API anahtarları, uygulamaların doğrudan CLI'ler aracılığıyla API'lerle iletişim kurması gereken senaryolar için uygundur. Örneğin, OpenAI API'lerini aramak.
  • Genel API'ler: API'leri halka açarken, API anahtarları basit bir erişim kontrol yöntemi sağlar.
  • Basitleştirilmiş kurulum: Özellikle geliştirme aşamasında hızlı ve basit kimlik doğrulama ihtiyaçları için. Logto M2M'nin aksine, API anahtarları önceden istemci kaydı gerektirmez ve erişim belirteci almak için değiş tokuş yapmanız gerekmez. Sadece isteğinizde API anahtarınızı bir parametre olarak geçersiniz ve bu basitçe çalışır.

Kişisel Erişim Belirteci (PAT)

  • Kullanıcıya özel eylemler: Bir uygulamanın bir kullanıcı adına eylemler gerçekleştirmesi gerektiğinde.
  • Ayrıntılı erişim kontrolü (kullanıcı): Bir kullanıcının gerçekleştirebileceği eylemler üzerinde hassas kontrol gerektiğinde.

Logto Makineden Makineye (Logto M2M)

  • Güvenlik: Logto M2M, yalnızca güvenilir istemcilerin arka uç hizmetlere erişmesine izin verildiği senaryolar için idealdir.
  • Ayrıntılı erişim kontrolü (istemci): Bir uygulamanın gerçekleştirebileceği eylemler üzerinde hassas kontrol gerektiğinde.

Sonuç

Özetle, API anahtarları, PAT'ler ve Logto M2M arasındaki seçim, uygulamanızın kullanıcıya özel eylemler, makineden makineye iletişim veya her ikisinin bir kombinasyonunu içerip içermediğine dair özel gereksinimlerine bağlıdır. Güvenlik ve fonksiyonellik ihtiyaçlarını değerlendirerek kullanım durumunuza en uygun kimlik doğrulama yöntemini belirleyin.

Logto M2M mekanizması, kullanıcılara RBAC (Rol Tabanlı Erişim Kontrolü) özelliği üzerinde ayrıntılı erişim kontrolleri ayarlama imkanı tanır. Yakın gelecekte API anahtarı ve PAT desteğini de sağlamayı planlıyoruz. Lütfen özellik güncellemelerimizi takip edin!