Tek bir makalede IAM, OAuth, OpenID Connect, SAML, SSO ve JWT'yi Anlayın

Kimlik ve erişim yönetimi (IAM) alanı son yıllarda daha karmaşık hale geldi. OAuth, OpenID Connect (OIDC), SAML, SSO ve JWT gibi süslü terimler sıkça kullanılır, ama bunlar ne anlama gelir? Nasıl birlikte çalışırlar? Bu kavramları ve çerçeveleri daha anlaşılır ve pratik hale getirmek için keşfedelim.

IAM Nedir?#

Kimlik ve erişim yönetimi (IAM), dijital kimliklerin yönetimi ve erişim kontrolü uygulamasını içeren geniş bir kavramdır. Daha önce bahsedilen çerçeveler ve protokoller IAM kapsamına girer ve bu alanın belirli zorluklarına her biri tarafından hitap edilir.

Özünde, IAM şu anlama gelir:

• Kimlik: Bir kullanıcı, hizmet veya cihazın dijital temsili. Bir kimlik genellikle adı, e-posta, roller vb. gibi nitelikleri içerir ve varlığı tanımlar.
• Erişim: Kaynaklarla etkileşime geçme, eylemler gerçekleştirme veya hizmetleri kullanma yeteneği. Erişim, hangi eylemlerin hangi kaynaklar üzerinde gerçekleştirilebileceğini tanımlar.

Yukarıdaki diyagramda, bir kullanıcı (kimlik), bir API (kaynak) üzerinde GET isteği gerçekleştirmek istiyor. Kullanıcının adı, e-postası ve rolü gibi nitelikler kimliği tanımlar.

Kimlik doğrulama vs. yetkilendirme#

Kimlik doğrulama ve yetkilendirme genellikle IAM tartışmalarında birlikte görünür. Tanımlarını netleştirelim:

• Kimlik doğrulama: Bir kimliğin sahipliğini doğrulama süreci. "Hangi kimliğe sahipsin?" sorusunu yanıtlar.
• Yetkilendirme: Kimliği doğrulanmış bir kullanıcının bir kaynak üzerinde hangi eylemleri gerçekleştirebileceğini belirleme süreci. "Ne yapabilirsin?" sorusunu yanıtlar.

Önceki örnekte:

• Kullanıcı (kimlik) herhangi bir eylem gerçekleştirmeden önce, kimlik doğrulama sürecini tamamlamalıdır.
• Kimlik doğrulama sonrasında, sistem kullanıcının API (kaynak) üzerinde GET isteği (eylem) gerçekleştirebilir mi, yani yetkilendirme sürecini tamamlamalıdır.

---

Bu temel bilgiyle donandıktan sonra diğer kısaltmalar ve protokolleri deşifre edelim.

OAuth#

OAuth 2.0, genellikle OAuth olarak anılır, başka bir uygulamadaki korunmuş kaynaklara (genellikle bir kullanıcı adına) erişim sağlamak için bir yetkilendirme çerçevesidir.

Örneğin, MyApp adlı bir web uygulamanız olduğunu ve bir kullanıcının Google Drive'ına erişmek istediğini hayal edin. Kullanıcıdan Google Drive kimlik bilgilerini paylaşmasını istemek yerine, MyApp OAuth 2.0 kullanarak kullanıcıyı temsilen Google’dan Drive'larına erişim için izin (yetkilendirme) talep edebilir.

İşte OAuth akışını basitleştirilmiş bir diyagram:

Bu akışta:

• MyApp Google Drive (kaynak) erişimi talep eden istemci (kimliktir).
• Kullanıcı (kaynak sahibi) 6. adımda MyApp'e izin vererek yetkilendirme sürecini tamamlar.

OAuth 2.0'da önemli bir unsur erişim belirtecidir; istemci, bu belirteci kullanarak kullanıcının kaynaklara erişim yetkisini gösterir. Detaylar için Erişim belirteci'ne bakın.

OpenID Connect (OIDC)#

OpenID Connect (OIDC), OAuth 2.0'ın üzerine inşa edilmiş bir kimlik doğrulama katmanıdır. Kimlik doğrulama için ID belirteçleri ve bir Kullanıcı Bilgileri uç noktası gibi özellikler ekleyerek hem kimlik doğrulama hem de yetkilendirme amacıyla uygun hale gelir.

OAuth akışını yeniden ziyaret edersek, OIDC'nin eklenmesi bir ID belirteci getirir. Bu belirteç, kullanıcının kimliği hakkında bilgi içerir ve MyApp'in kullanıcının kimliğini doğrulamasını sağlar.

Örnek senaryo: "Google ile Giriş Yap"#

Örnekleri değiştirelim. Eğer MyApp, kullanıcıların Google hesaplarını kullanarak giriş yapmalarına izin vermek istiyorsa, amaç kaynak erişiminden ziyade kimlik doğrulama olur. Bu durumda, OIDC daha uygun bir çözüm olacaktır. OIDC akışı şu şekildedir:

Anahtar Fark: Erişim belirsine ek olarak, OIDC ID belirteci de sağlar ve MyApp, kullanıcının kimliğini doğrulamak için ek taleplere gerek kalmadan doğrulama yapabilir.

OIDC, OAuth 2.0'ın izin tanımlarını paylaşır, bu da iki çerçeve arasında uyumluluk ve tutarlılığı sağlar.

SAML#

Güvenlik Beyanı İşaretleme Dili (SAML), taraflar arasında kimlik doğrulama ve yetkilendirme verilerini değiştirmenin XML tabanlı bir çerçevesidir. 2000'lerin başında tanıtılan SAML, kurumsal ortamlarda geniş çapta benimsenmiştir.

SAML OIDC ile Nasıl Karşılaştırılır?#

SAML ve OIDC, işlevsel olarak benzer olsalar da uygulama detaylarında farklılık gösterir:

• SAML: XML tabanlı beyannameler kullanır ve genellikle daha karmaşık olarak değerlendirilir.
• OIDC: JSON ve JWT kullanarak daha hafif ve geliştirici dostu hale gelir.

Modern uygulamalar, basitlik ve esneklik nedeniyle genellikle OIDC'yi tercih eder, ancak SAML eski sistemlerde ve kurumsal kullanımlarda yaygın kalır.

Tek oturum açma (SSO)#

Tek oturum açma (SSO), kullanıcıların tek bir kimlik bilgisi setiyle birden fazla uygulama ve hizmete erişim sağlamasını enable eder. Kullanıcı her bir uygulama için ayrı ayrı giriş yapmak yerine, bir kez giriş yapar ve bağlı tüm sistemlere erişim sağlar.

SSO Nasıl Çalışır?#

SSO, kullanıcı kimliklerini yönetmek için merkezi bir kimlik sağlayıcı (IdP) kullanır. IdP, kullanıcıyı doğrular ve bağlantılı uygulamalara kimlik doğrulama ve yetkilendirme gibi hizmetler sağlar.

IdP, OIDC, OAuth 2.0, SAML veya diğer protokolleri bu hizmetleri sağlamak için kullanabilir. Tek bir IdP, farklı uygulamaların çeşitli ihtiyaçlarını karşılamak için birden fazla protokolü destekleyebilir.

OIDC Tabanlı SSO Örneği#

OIDC tabanlı SSO'nun bir örneğini inceleyelim:

Bu akışta, kullanıcı IdP'ye bir kez giriş yapar ve birden fazla uygulama (AppA ve AppB) arasında doğrulanır.

Kurumsal SSO#

SSO geniş bir kavram olmasına rağmen, kurumsal SSO terimiyle karşılaşabilirsiniz. Bu, (genellikle çalışanlar ve ortaklar için) kurumsal ortamlar için tasarlanmış belirli bir tür SSO'yu ifade eder.

Bir müşteri, uygulamanız için SSO talebinde bulunduğunda, ihtiyaçlarını ve kullandıkları protokolleri netleştirmek önemlidir. Çoğu durumda, belirli e-posta alanları için, uygulamanızın kullanıcıları kimlik doğrulama için IdP'lerine (kurumsal SSO'yu uygulayan) yönlendirmesini isterler.

Bir Kurumsal SSO Sağlayıcısı Ekleme Örneği#

Aşağıda, uygulamanız (MyApp) ile bir kurumsal SSO sağlayıcısı (Banana) entegrasyonunun basitleştirilmiş bir örneği verilmiştir:

JWT#

JSON Web Token (JWT), iki taraf arasında güvenli iletişimi sağlayan RFC 7519 tarafından tanımlanan açık bir standarttır. OIDC'de ID belirteçleri için standart format olarak kullanılır ve OAuth 2.0 erişim belirteçleri için de yaygın olarak kullanılmaktadır.

JWT'nin anahtar özellikleri şunlardır:

• Kompakt: JWT'ler, iletimi ve saklanması kolay kompakt bir formatta kodlanmış JSON nesneleridir.
• Kendine yeterli: JWT'ler, kullanıcı ve belirtecinin kendisi hakkında gerekli tüm bilgileri içerir.
• Doğrulanabilir ve şifrelenebilir: JWT'ler, veri bütünlüğünü ve gizliliği sağlamak için imzalanabilir ve şifrelenebilir.

Tipik bir JWT şu şekilde görünür:

Bu JWT, noktalarla ayrılmış üç bölümden oluşur:

• Header: Belirteç tipini ve imzalama algoritmasını gibi belirteci hakkında meta veri içerir.
• Payload: Kimlik ve belirteci hakkında bilgileri içerir.
• Signature: Belirtecin bütünlüğünü doğrular.

Hem başlık hem de yük, base64-encoded JSON nesnelerdir. Yukarıdaki JWT şu şekilde çözülebilir:

JWT kullanarak, istemci belirteci çözüp kullanıcı bilgilerini çıkarabilir, kimlik sağlayıcısına ek talepler yapmadan. JWT hakkında daha fazla bilgi almak için JSON Web Token (JWT)'ye bakın.

Yeniden Değerlendirme#

Bu makalede birçok konuyu ele aldık. Ana noktaları bir örnekle özetleyelim:

Bir kimlik ve erişim yönetimi (IAM) çözümüne ihtiyaç duyan bir web uygulamanız, AppA'nın olduğunu hayal edin. OpenID Connect (OIDC)'yi kimlik doğrulama için kullanan bir kimlik sağlayıcısı Logto'yu seçersiniz. OIDC, OAuth 2.0 üzerine kurulu olduğundan, Logto aynı zamanda uygulamanız için yetkilendirmeyi de destekler.

Kullanıcılarınız için sürtünmeyi azaltmak amacıyla, Logto'da "Google ile Giriş Yap" özelliğini devreye sokarsınız. Bu, Logto ve Google arasında yetkilendirme verileri ve kullanıcı bilgilerini değiş tokuş etmek için OAuth 2.0 kullanır.

Kullanıcı Logto üzerinden AppA'ya giriş yaptıktan sonra, AppA, kullanıcının bilgilerini içeren bir JSON Web Token (JWT) olan bir kimlik belirteci alır.

İşiniz büyüdükçe, kullanıcı kimlik doğrulamasına ihtiyaç duyan yeni bir uygulama, AppB başlatırsınız. Logto zaten kurulu olduğundan, AppB için aynı kimlik doğrulama akışını yeniden kullanabilirsiniz. Kullanıcılarınız artık tek bir kimlik bilgisi setiyle hem AppA hem de AppB'ye giriş yapabilirler, bu özelliğe tek oturum açma (SSO) denir.

Daha sonra, bir iş ortağı SAML kullanan kurumsal SSO sistemlerini bağlamanızı ister. Logto'nun SAML bağlantılarını desteklediğini görürsünüz, bu yüzden Logto ile ortağın SSO sistemi arasında bir bağlantı kurarsınız. Artık, iş ortağının organizasyonundan kullanıcılar da mevcut kimlik bilgilerini kullanarak AppA ve AppB'ye giriş yapabilir.

---

Umarım bu makale bu kavramları sizin için netleştirmiştir. Daha derinlemesine açıklamalar ve örnekler için Auth Wiki'yi inceleyin. Uygulamanız için bir IAM çözümü arıyorsanız, zaman ve çaba tasarrufu için Logto gibi yönetilen bir hizmet kullanmayı düşünün.