Kişisel erişim belirteçleri, makineden makineye kimlik doğrulama ve API Anahtarları tanımı ve gerçek dünya senaryoları

Bir yazılım veya SaaS ürünü geliştiriyorsanız, sık sık geniş bir kullanım durumu veya özellik isteğiyle karşılaşırsınız: API istekleri. Özellikle daha büyük kurumsal müşteriler, programatik olarak kaynaklara erişim isteyebilir. Bu, kişisel düzeyde veya organizasyonel düzeyde olabilir.

Bu durumlarda, API anahtarları, Kişisel Erişim Belirteçleri (PAT'ler) ve Makineden Makineye (M2M) kimlik doğrulama genellikle gerekli olacaktır. Bu makalede, bu yöntemler arasındaki farklılıkları ve bunların B2B ürün geliştirmede geliştiriciler için nasıl kullanılabileceğini keşfedeceğiz.

Benzerlikler#

Öncelikle bu üç yöntemin benzerliklerine bir göz atalım.

1. Güvenlik amacı: Bu üç yöntem de API'lere, hizmetlere veya kaynaklara erişimi güvence altına almak ve kontrol etmek için kullanılır. Hepsi kimlik doğrulama ve/veya yetkilendirme aracı olarak hizmet eder.
2. Belirteç tabanlı yaklaşım: Her yöntemde genellikle kimlik doğrulamak için benzersiz bir dize veya belirteç kullanılır. Bu belirteçler genellikle API istekleri ile birlikte, genellikle başlıklarda veya sorgu parametrelerinde gönderilir.
3. Geri alınabilir: Bu üç yöntemde de belirteçler veya anahtarlar, güvenliği tehlikeye girerse veya artık gerekli değilse iptal edilebilir veya geçersiz kılınabilir. Bu, temel sistemi değiştirmeden hızlı güvenlik tepkileri verilmesine olanak tanır.
4. Programlanabilir erişim: Bu üç yöntem de API'lere veya hizmetlere programatik erişim sağlar. Farklı sistemler veya uygulamalar arasında otomasyon ve entegrasyon sağlar.
5. Denetleme özelliği: Bu kimlik doğrulama yöntemlerinin kullanımı kaydedilebilir ve denetlenebilir. Bu, API erişimini izlemeye, şüpheli etkinlikleri izlemeye ve uyumluluk raporlamasına olanak tanır.
6. Erişim kontrolüne uyarlanabilir: Üç yöntem de farklı erişim kontrolü ve izin düzeyleri ile uygulanabilir. Farklı güvenlik modellerine ve mimari gereksinimlere uyarlanabilir.
7. Protokol bağımsızlığı: Genellikle REST API'lerde kullanılsa da, bu yöntemler çeşitli API ve protokol türlerine uygulanabilir.

Bu benzerlikleri anlamak, bu kimlik doğrulama yöntemlerinin ortak temellerini tanımanıza yardımcı olur. Farklılıkları, belirli kullanım durumları ve güvenlik gereksinimleri için en uygun çözümü seçmenizi sağlar.

Şimdi, kullanım durumlarına ve her yöntemin ne zaman kullanılacağına odaklanarak farklılıklarını inceleyelim.

Farklılıklar#

API Anahtarları#

API anahtarları çağrı yapan uygulama veya hizmeti tanımlamak ve yetkilendirmek için kullanılır. Genellikle uzun ömürlüdürler ve döndürülene kadar statik kalırlar ve genellikle sabit bir izin kümesine sahiptirler. Ana olarak sunucudan sunucuya iletişimler veya herkese açık verilere erişim için kullanılırlar, bu belirteçler genellikle belirli bir kullanıcıyı temsil etmez.

API anahtarları nasıl çalışır?#

Bir API anahtarı, bir API sağlayıcısı tarafından verilir ve kayıtlı bir API tüketicisine [1] verilir. Bu tüketici, her istekte bu anahtarı içerir. API sunucusu, sağlanan API anahtarını kontrol ederek tüketicinin kimliğini doğrular ve ardından istenen verileri geri döner.

API anahtarları, API kimlik doğrulama gibi diğer OAuth ve JWT gibi yöntemler kadar etkili olmasa da, API üreticilerinin kullanım izleme ve hassas verileri güvende tutmada önemli bir rol oynar.

[1]: API tüketicisi, bir API ile etkileşime giren herhangi bir uygulama, hizmet veya kullanıcıdır. API üzerinden işlemler gerçekleştirmek için istekler gönderirler, örneğin veri alma, oluşturma, güncelleme veya silme işlemleri. API tüketicileri, web uygulamalarından, mobil uygulamalardan, diğer sunuculardan veya API'yi diğer hizmetlerle entegre etmek veya mevcut platformların üzerine yeni işlevler inşa etmek için kullanan bireysel geliştiricilere kadar çeşitlilik gösterebilir.

Postman: API anahtarı nedir?

Kullanım durumları#

API anahtarı kullanım durumları tartışıldığında, genellikle otomasyon, veri paylaşımı, test, geliştirme ve güvenlik kontrolü gibi teknik konular ortaya çıkar. Bununla birlikte, gerçek dünya senaryolarında, ürün geliştirirken en yaygın amaç entegrasyondur.

Örnek 1: Zapier ile Entegrasyon#

Zapier: API Anahtarı ile kimlik doğrulaması ekleyin

Zapier, farklı web uygulamalarını bağlayan popüler bir otomasyon aracıdır. Zapier ile bir uygulamayı entegre ederken, API anahtarları uygulama API'sine erişimi kimlik doğrulamak ve yetkilendirmek için kullanılır. Örneğin, bir CRM sistemi ile bir e-posta pazarlama aracını otomatikleştirmek isterseniz, CRM sisteminden bir API anahtarı oluşturur ve bunu Zapier'e sağlarsınız. Bu anahtar, Zapier'in CRM'in API'si üzerinden istekleri kimlik doğrulamak için kullanılır ve iki sistem arasında verilerin güvenli bir şekilde akışını sağlar.

Örnek 2: Stripe ile Entegrasyon#

Stripe, çeşitli platformlar ve uygulamalarla güvenli entegrasyon için API anahtarlarını kullanır. Geliştirici Paneli üzerinden API anahtarlarını oluşturabilir, görebilir, silebilir ve döndürebilirsiniz.

Kişisel Erişim Belirteçleri (PAT'ler)#

Kişisel erişim belirteci, başka bir benzer kavramdır, ancak belirli bir kullanıcının kimliğini ve izinlerini temsil eder, başarılı bir kimlik doğrulama veya giriş sırasında dinamik olarak oluşturulur ve genellikle sınırlı bir ömre sahiptir ancak yenilenebilir. Kullanıcıya özel verilere ve yeteneklere ince ayrıntılı erişim sağlar ve genellikle CLI araçları, betikler veya kişisel API erişimi için kullanılır.

PAT'ler nasıl çalışır#

1. Oluşturma ve yönetim: Kullanıcılar, ilgili platformdaki hesap ayarları üzerinden PAT'ler oluşturur.
   • Örneğin, GitHub'da kullanıcılar, belirli izinler ve sona erme tarihleriyle ince ayrıntılı veya klasik PAT'ler oluşturabilir.
   • Jira ve Confluence gibi Atlassian ürünlerinde kullanıcılar, profillerinde PAT'ler oluşturabilir ve belirtecin adını ve isteğe bağlı olarak sona erme tarihini belirleyebilir.
2. Kullanım: PAT'ler API isteklerinde Yetkilendirme başlığında taşıyıcı belirteçler olarak kullanılır. Bu, HTTP başlıklarına dahil edilerek isteğin kimliğinin doğrulanması anlamına gelir.
   • Kullanıcılara, belirtece verilen izinler doğrultusunda kaynakları oluşturma, okuma, güncelleme ve silme işlemlerini gerçekleştirme imkanı tanır.
   • PAT'ler, bir platform içindeki birden fazla uygulamada kullanılabilir, bu da erişim ve izinleri yönetmenin birleşik bir yolunu sağlar.
3. Geri alma ve geçerlilik süresi ayarlama:
   • PAT'ler, kullanıcıların güvenliği tehlikeye girmiş belirteçleri iptal edebilmesine olanak tanıyarak, hesap şifresini değiştirmeye gerek kalmadan güvenliği artırır.
   • Platformlar genellikle PAT'ler için sona erme tarihlerinin ayarlanmasını önerir, böylece uzun ömürlü belirteçlerin riskini azaltır.

Kullanım durumları#

İki tipik senaryo vardır,

Otomasyon ve betikleme

Bu, bir geliştiricinin kodun bir depodan üretim ortamına dağıtımını otomatikleştirmek için bir PAT kullanması anlamına gelir; bu, manuel müdahaleyi azaltır ve tutarlılığı sağlar.

Örneğin, GitHub kullanıcıları, HTTPS üzerinden Git işlemlerini kimlik doğrulamak ve GitHub'ın REST API'siyle etkileşim kurmak için PAT'ler oluşturabilir. Bu, depoları klonlamak, taahhütleri göndermek veya sorunları ve çekme isteklerini yönetmek gibi görevleri otomatikleştirmesi gereken geliştiriciler için faydalıdır.

Dış uygulamalarla entegrasyon

Bu, farklı sistemler ve uygulamalar arasında güvenli iletişimi sağlama anlamına gelir. Bu, API anahtarı entegrasyon senaryosuna benzese de, PAT kullanıcıyı temsil eder, istemci veya uygulamayı değil.

Örneğin, bir proje yöneticisi, bir proje yönetim aracını bir dış sorun takip sistemi ile entegre etmek için bir PAT kullanır; böylece verilerin sorunsuz bir şekilde paylaşımı ve senkronizasyonu sağlanır, örneğin Atlassian (Jira ve Confluence) gibi.

Yukarıdaki senaryolar daha çok geliştirici araçlarına benziyor. Peki, PAT'ler sadece bu tür ürünler için mi kullanılır? Hayır. İşte iki ek örnek: biri bir CMS sistemi, diğeri bir üretkenlik aracı.

Örnek 1: Contentful#

Contentful: Kişisel Erişim Belirteçleri

Contentful, bir başsız CMS platformudur ve Kişisel Erişim Belirteçleri (PAT'ler), İçerik Yönetim API'sine (CMA) erişim sağlamak için OAuth belirteçlerine alternatif olarak sunar.

Ana özellikler şunları içerir:

• Kullanıcılar, farklı kapsamlar ve izinler ile birden fazla belirteç oluşturabilir.
• Belirteçler, kullanıcının hesabına bağlıdır ve onların izinlerini devralır.
• PAT'ler, özellikle geliştirme ve otomasyon amaçları için kullanışlıdır.

Örnek 2: Airtable#

Kişisel Erişim Belirteçleri Oluşturma | Airtable Desteği

Airtable - bir bulut işbirliği platformu, API erişimi için PAT'leri uygular.

Sistemleri şunlara olanak tanır:

• Farklı kapsamlar ve erişim seviyeleri ile birden fazla belirteç oluşturma.
• Belirteçler, belirli tabanlar veya çalışma alanlarıyla sınırlanabilir.
• Kurumsal yöneticiler, organizasyon genelinde daha geniş erişime sahip belirteçler oluşturabilir.

Makineden Makineye (M2M) kimlik doğrulama#

M2M, insan müdahalesi olmadan hizmetten hizmete iletişim için tasarlanmıştır. Kullanıcı adları ve şifrelerin hizmetleri korumak için yeterli olmadığı ve etkili otomasyon için verimli olmadığı fikrinden kaynaklanır.

Makineden makineye (M2M) uygulamalar, artık OAuth 2.0 RFC 6749 yetkilendirme protokolü tarafından tanımlanan İstemci Kimlik Bilgileri Akışını benimsemektedir. Benzer standart protokoller de desteklenebilir. Evet, M2M kimlik doğrulaması, PAT ve API anahtarlarına kıyasla açık standartlara daha fazla bağlıdır.

Kullanıcının değil, uygulamanın veya hizmetin kendisinin kimlik doğrulamasını gerçekleştirir ve genellikle stateless kimlik doğrulama için JWT (JSON Web Tokens) uygular. Bu, dağıtık sistemlerde hizmetlerin birbirleriyle güvenli bir şekilde etkileşimde bulunmasını sağlar.

Makineden makineye kimlik doğrulama nasıl çalışır#

Benzer bir süreç izler:

1. İstemci Kimlik Bilgileri: Her makine (veya hizmet) benzersiz bir istemci kimliği ve gizli anahtarına sahiptir.
2. Belirteç Talebi: Hizmet bu kimlik bilgilerini yetkilendirme sunucusuna gönderir.
3. Erişim Belirteci: Kimlik doğrulama başarılı olursa yetkilendirme sunucusu bir erişim belirteci (genellikle bir JWT) verir.
4. API İstekleri: Hizmet bu belirteci kullanarak başka bir hizmete kimlik doğrulaması ve yetkilendirme amaçlı API istekleri gönderir.
5. Doğrulama: Alıcı hizmet, belirteci doğruladıktan sonra kendi kaynaklarına erişim sağlar.

Kullanım durumları#

Makineden makineye (M2M) kimlik doğrulamasının arka uçtan arka uca iletişim için kullanıldığı bir örnek:

Senaryo: Hizmet A, Hizmet B’nin API'sinden veri almak istiyor.

1. Kurulum:

   • Hizmet A, bir yetkilendirme sunucusuna istemci olarak kaydedilmiştir.
   • Hizmet A’ya bir istemci kimliği ve istemci gizli anahtarı verilmiştir.

2. Kimlik doğrulama:

   • Hizmet A, yetkilendirme sunucusundan bir erişim belirteci talep eder:

3. Belirteç Verilmesi:

   • Yetkilendirme sunucusu kimlik bilgilerini doğrular ve bir JWT erişim belirteci verir.

4. API İsteği:

   • Hizmet A, belirteci kullanarak Hizmet B'den veri talep eder:

5. Doğrulama:

   • Hizmet B, belirteci yetkilendirme sunucusuna doğrular.

6. Yanıt:

   • Eğer geçerli ise, Hizmet B, talep edilen verileri Hizmet A’ya geri döner.

Bu işlem, Hizmet A ve Hizmet B arasında kullanıcı müdahalesi olmadan güvenli, otomatikleşmiş iletişime olanak tanır. Bu, OAuth 2.0 istemci kimlik bilgileri akışını kullanır.

Cihazdan cihaza iletişim

Cihazdan cihaza iletişim, özellikle IoT (Nesnelerin İnterneti) bağlamında, güvenli ve verimli veri alışverişini sağlamak için makineden makineye (M2M) kimlik doğrulamasına büyük ölçüde dayanır.

Örneğin, akıllı ev cihazlarında, bir akıllı termostat, kullanıcı tercihleri doğrultusunda sıcaklık ayarlarını düzenlemek için merkezi bir ev otomasyon merkezi ile iletişim kurar. Termostat, verileri merkeziye güvenli bir şekilde göndermek ve komutlarını almak için M2M kimlik doğrulaması kullanır, bu da sadece yetkili cihazların evin ısınma sistemiyle etkileşim içine girmesini sağlar.

Ana özet#

Tamam, bu makalenin sonuna geldiniz. Kısa bir özet alabilir miyim? Elbette! İşte temel noktaların bir özeti:

1. Kapsam: API anahtarları geniştir, PAT'ler (Kişisel Erişim Belirteçleri) kullanıcıya özgüdür ve M2M (Makineden Makineye) belirteçler hizmete özgüdür.
2. Ömür: API anahtarları uzun ömürlüdür, PAT'lerin kısa bir ömrü vardır ve M2M belirteçler değişebilir.
3. Temsil: API anahtarları opak dizelerdir, PAT'ler opak veya yapısal olabilir ve M2M belirteçler genellikle JWT'leri kullanır.
4. Kullanım Durumu: API anahtarları basit API erişimi içindir, PAT'ler kullanıcı merkezli işlemler içindir ve M2M belirteçleri hizmetten hizmete iletişim içindir.