[Kimlik ve erişim yönetimi (IAM)](https://auth.wiki/iam) alanı son yıllarda daha karmaşık hale geldi. [OAuth](https://auth.wiki/oauth), [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), [SAML](https://auth.wiki/saml), [SSO](https://auth.wiki/single-sign-on) ve [JWT](https://auth.wiki/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. Bu protokollerin ve çerçevelerin her biri daha derinlemesine incelenebilir. Bu makale temel bir anlayış sağlamayı amaçlamaktadır. Her bir konu hakkında ayrıntılı görünüm için [Auth Wiki](https://auth.wiki)'yi ziyaret edin. ## 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. ```mermaid graph LR subgraph Kullanıcı Ad Eposta Rol end API Kullanıcı -->|GET| API ``` 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. Yetkilendirme, erişim kontrolünün bir alt kümesidir. Erişim kontrolü, yetkilendirme ve diğer kısıtlamaları içeren daha geniş bir kavramdır. Daha fazla detay için [erişim kontrolü](https://auth.wiki/access-control)'ne bakın. Ö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](https://auth.wiki/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: ```mermaid sequenceDiagram autonumber actor Kullanıcı participant MyApp participant Google Kullanıcı->>MyApp: MyApp'i aç ve
"Google Drive'a Bağlan" butonuna tıkla MyApp->>Google: İzin talebiyle Google'a yönlendir Google->>Kullanıcı: Google giriş ekranı aç Kullanıcı->>Google: Giriş yap Google->>Kullanıcı: Google Drive erişim izni iste Kullanıcı->>Google: MyApp'e erişim sağla Google->>MyApp: Erişim belirteci ile MyApp'e yönlendir MyApp->>Google: Erişim belirteci kullanarak Google Drive'a erişim sağla ``` 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, kullanıcıların Google'a nasıl kimlik doğrulaması yapacaklarını (3. ve 4. adımlar) tanımlamaz. Bu kısım Google'ın uygulamasına bırakılmıştır. OAuth 2.0'da önemli bir unsur **erişim belirteci**dir; istemci, bu belirteci kullanarak kullanıcının kaynaklara erişim yetkisini gösterir. Detaylar için [Erişim belirteci](https://auth.wiki/access-token)'ne bakın. ## OpenID Connect (OIDC) [OpenID Connect (OIDC)](https://auth.wiki/openid-connect), OAuth 2.0'ın üzerine inşa edilmiş bir **kimlik doğrulama** katmanıdır. Kimlik doğrulama için [ID belirteçleri](https://auth.wiki/id-token) ve bir [Kullanıcı Bilgileri uç noktası](https://auth.wiki/userinfo-endpoint) 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: ```mermaid sequenceDiagram autonumber actor Kullanıcı participant MyApp participant Google Kullanıcı->>MyApp: "Google ile Giriş Yap" butonuna tıkla MyApp->>Google: Kimlik doğrulama talebiyle yönlendir Google->>Kullanıcı: Google giriş ekranı çıkart Kullanıcı->>Google: Giriş yap Google->>Kullanıcı: Kullanıcı bilgilerini paylaşma izni iste Kullanıcı->>Google: İzin ver Google->>MyApp: ID ve erişim belirteçleriyle MyApp'e yönlendir MyApp->>MyApp: ID belirtecinden kullanıcı bilgilerini doğrula ve çıkar ``` **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ı](https://auth.wiki/oauth-2.0-grant) paylaşır, bu da iki çerçeve arasında uyumluluk ve tutarlılığı sağlar. ## SAML [Güvenlik Beyanı İşaretleme Dili (SAML)](https://auth.wiki/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)](https://auth.wiki/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)](https://auth.wiki/identity-provider) kullanır. IdP, kullanıcıyı doğrular ve bağlantılı uygulamalara kimlik doğrulama ve yetkilendirme gibi hizmetler sağlar. ```mermaid graph LR User --> AppA User --> AppB AppA <--> IdP[Kimlik Sağlayıcı] AppB <--> IdP User -->|SSO| IdP ``` 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: ```mermaid sequenceDiagram actor Kullanıcı participant AppA participant AppB participant IdP Kullanıcı->>AppA: Uygulama A'ya eriş AppA->>IdP: IdP'ye yönlendir IdP->>Kullanıcı: Kimlik bilgilerini gir Kullanıcı->>IdP: Kimlik bilgilerini sağla IdP->>AppA: ID belirteci gönder AppA->>Kullanıcı: Erişim ver Kullanıcı->>AppB: Uygulama B'ye eriş AppB->>IdP: IdP'ye yönlendir IdP->>IdP: Kullanıcı zaten doğrulandı IdP->>AppB: ID belirteci gönder AppB->>Kullanıcı: Erişim ver ``` 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](https://auth.wiki/enterprise-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: ```mermaid sequenceDiagram actor Kullanıcı participant MyApp participant IdP as MyApp IdP participant Banana as Banana IdP Kullanıcı->>MyApp: "Giriş Yap" butonuna tıkla MyApp->>IdP: IdP'ye yönlendir IdP->>Kullanıcı: Kimlik bilgilerini sağla Kullanıcı->>IdP: Banana e-posta sağla IdP->>Banana: Banana IdP'ye yönlendir Banana->>Kullanıcı: Kimlik bilgilerini sağla Kullanıcı->>Banana: Kimlik bilgilerini sağla Banana->>IdP: Yanıt gönder IdP->>MyApp: Yanıt gönder MyApp->>Kullanıcı: MyApp'e erişim sağla ve kullanıcı verilerini göster ``` IdP'ye yönlendirme, SSO akışlarında yaygın bir kalıptır. Bu yaklaşım, IdP'nin kullanıcı oturumları için merkezi bir nokta olarak kalmasını sağlarken birden fazla uygulamaya kimlik doğrulama ve yetkilendirme hizmetleri sunar. ## JWT [JSON Web Token (JWT)](https://auth.wiki/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: ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ.XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g ``` Bu JWT, noktalarla ayrılmış üç bölümden oluşur: ``` {{header}}.{{payload}}.{{signature}} ``` - **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: ```jsonc // Header { "alg": "HS256", "typ": "JWT" } // Payload { "sub": "foo", "name": "John Doe" } ``` 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)](https://auth.wiki/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](https://auth.wiki)'yi inceleyin. Uygulamanız için bir IAM çözümü arıyorsanız, zaman ve çaba tasarrufu için [Logto](https://logto.io) gibi yönetilen bir hizmet kullanmayı düşünün.