OAuth/OIDC'de Token Değişimini Anlamak

RFC 8693 ile tanıtılan token değişimi, güvenilen istemcilerin mevcut bir token'ı farklı özniteliklere veya kapsamlı yeni bir token ile değiştirmesine izin veren bir OAuth uzantısıdır. Bu mekanizma, bir hizmetin, bir uygulamanın veya bir son kullanıcının, baştan sona OAuth akışını tamamlamaya gerek kalmadan, önceden yetkilendirilmiş bir token aracılığıyla normal bir OAuth erişim token'ı elde etmesi için özellikle yararlıdır.

Yetkilendirme kodu akışı ile karşılaştırma#

Öncelikle, bir erişim token'ı elde etmek için en yaygın akış olan OAuth Yetkilendirme Kodu akışına bir göz atalım.

Ve bu, token değişim akışıdır:

Yönlendirme#

Ana fark, yetkilendirme kodu akışında, istemci uygulamanın, bir erişim token'ı almak için kullanıcıyı yetkilendirme sunucusuna yönlendirmesidir. Token değişiminde, istemci uygulama bir token'ı, kullanıcıyı yönlendirmeye gerek kalmadan yetkilendirme sunucusu ile değiştirebilir.

Bunun sebebi, yetkilendirme kodu akışında, istemci uygulamanın "güvenilir" olmaması ve bir erişim token'ı almak için kullanıcının kimlik bilgilerini bilmesi gerekmesidir. Token değişiminde ise istemci uygulama, kullanıcıdan token'ı zaten almış olan güvenilir kabul edilir ve yetkilendirme sunucusu token'ı doğrulayıp yeni bir tane verir.

Token sağlayıcı ve token değişim hizmeti#

Token değişim akışında, "Doğrulama Sunucusu" şimdi iki katılımcıdır:

1. Token sağlayıcı: Konu token'ı istemci uygulamaya verir.
2. Token değişim hizmeti: Konu token'ı doğrular ve istemci uygulamaya yeni bir token verir.

Token değişim hizmeti, yetkilendirme kodu akışındaki "Doğrulama Sunucusu" ile aynı olup, token sağlayıcı, bir üçüncü taraf kimlik sağlayıcısı olabilir veya "Doğrulama Sunucusu"ndan ayrılmış özel bir hizmet olarak düşünülebilir.

Ne zaman token değişimi kullanılır?#

Token değişim akışı, kullanıcı etkileşimi olmadan gerçekleştirilebilir, bu aşağıdaki senaryolarda yararlıdır:

• Taklit: Servislerin (örn. arka plan mikroservisleri) veya yönetici kullanıcıların, tam kullanıcı kimlik bilgilerini ifşa etmeden kullanıcı adına eylemler gerçekleştirmesine izin verir.
• Otomasyon: Güvenilir hizmetlerin, manuel müdahale olmadan otomatik olarak eylemler gerçekleştirmesine veya otomatik test yapmasına izin verir.
• Diğer Kimlik Sağlayıcılar ile Entegrasyon: Farklı kimlik sistemleri arasında tokenları dönüştürerek sorunsuz bir kullanıcı deneyimi sağlamak ve izinleri etkili bir şekilde yönetmek, yaygın bir senaryo, bir SSO token'ını aşağı akış hizmeti için bir token'a çevirmektir.
• Geçiş: Bir yetkilendirme sunucusundan diğerine tokenları geçirmek, örneğin eski bir sistemden modern bir OAuth/OIDC uyumlu sisteme.

Token değişim süreci#

Yeni bir erişim tokenı değişimi, en yaygın kullanım durumudur ve bunu bir örnek olarak ele alacağız. Erişim tokenı ile sınırlı olmamakla birlikte, token değişimi, yenileme tokenı, kimlik tokenı gibi diğer token türlerini çıkarmak için de kullanılabilir.

İstemci uygulama#

Token değişimini gerçekleştirmek için, yetkilendirme sunucusunda kayıtlı bir istemci uygulama gereklidir.

Ve istemci uygulama, token değişim akışını başlatmadan önce bir subject_token'a sahip olmalıdır, bu token genellikle yetkilendirme sunucusu veya güvenilen üçüncü taraf kimlik sağlayıcısı tarafından verilir. Bu tokena sahip olarak, istemci uygulama artık "güvenilir" kabul edilir ve kullanıcının kimlik bilgileri ve etkileşimi gerekmeden tokenları değiştirebilir.

Token değişim isteği#

İstemci, mevcut bir token'ı değiştirmek için yetkilendirme sunucusunun token uç noktasına bir istek gönderir. Bu, subject_tokenı (değiştirilecek token) ve isteğe bağlı olarak, hedef kitleyi, kapsamı ve token türünü içerir.

1. grant_type: GEREKLİ. Bu parametrenin değeri, bir token değişiminin gerçekleştirildiğini gösteren urn:ietf:params:oauth:grant-type:token-exchange olmalıdır.
2. subject_token: GEREKLİ. Kullanıcının PAT'si.
3. subject_token_type: GEREKLİ. subject_token parametresinde sağlanan güvenlik tokenının türü. Bu parametrenin yaygın bir değeri urn:ietf:params:oauth:token-type:access_token olup, değiştirilen tokena bağlı olarak farklılık gösterebilir.
4. resource: SEÇENEK. Erişim tokenı için hedef kaynağı belirtmeye yardımcı olan kaynak göstergesi.
5. audience: SEÇENEK. Tokenin amaçlanan alıcılarını belirten erişim tokenının kitlesi, yetkilendirme sunucusu audience belirtilmemişse resource değerini kullanabilir.
6. scope: SEÇENEK. İstenen kapsamlar.

Ayrıca, istek, Basic Auth başlığı veya form verileri olarak iletilebilen istemci bilgilerini içermelidir.

İşte bir örnek istek:

Logto'da Token Değişimi#

Logto, kutudan çıktığı gibi token değişimini destekler, taklit ve kişisel erişim tokenları dahil.