Ürününüzün Neden OAuth 2.0 ve OIDC'ye İhtiyacı Var - Özellikle AI Çağında
OAuth 2.0 ve OpenID Connect (OIDC)'nin modern kimlik doğrulama için, özellikle AI, ajanlar ve akıllı cihazlar çağında neden önemli olduğunu öğrenin. Bu makale, bu protokollerin hangi durumlarda uygulanacağını, doğru yetkilendirme sağlayıcısını nasıl seçeceğinizi ve ölçeklenebilirlik ve güvenlik için önemli kullanım durumlarını kapsıyor.
Logto'nun ilk günlerinden itibaren açık standartlara güçlü bir güvenle inşa ettik. OIDC, OAuth 2.0 ve SAML gibi protokolleri izlemeyi seçtik - sadece geniş çapta kullanıldıkları için değil, aynı zamanda endüstri genelinde güvenilen yerleşik, güvenli uygulamaları temsil ettikleri için. Güvenlik her zaman bizim için bir öncelikti. Açık kaynak ruhuna sadık kalmak ve Müşteri Kimliği Yönetimi ve modern kimlik doğrulama konusundaki en iyi uygulamalara bağlı kalmak da öyle.
Ama yol boyunca bir şey daha öğrendik:
OAuth 2.0 ve OIDC herkes için kolay değil. Bu protokollere yeni olan geliştiriciler için kavramlar yabancı ve bazen mantık dışı gelebiliyor. Bu, güvenlikten ödün vermeden geliştirici deneyimini nasıl basitleştireceğimizi düşünürken gerçek zorluklar yarattı.
İki nokta öne çıktı:
Entegrasyonu mümkün olduğunca sorunsuz hale getirmek için çok çalışmamıza rağmen, ID belirteçleri, erişim belirteçleri gibi temel kavramları anlamakla ilgili hala bir öğrenme eğrisi var.
Sıklıkla aldığımız bir soru: “Giriş ekranında yönlendirmeyi atlayabilir miyim?” Ne yazık ki, yönlendirme OIDC'nin nasıl çalıştığının temel bir parçasıdır ve güvenli kimlik doğrulama için gereklidir.
Discord kullanıcılarımızdan gelen ortak bir soru (kimlikleri ve avatarları gizliliği korumak için bulanıklaştırılmıştır).
Her karar beraberinde ödünler getirir - ama bazen, erken dönemde aldığınız bir karar, yeni kullanım durumları ortaya çıktığında özellikle değerli olur. Ve şu anda yeni bir çağa; AI çağına giriyoruz.
Bu makalede, ürününüzün ne zaman OIDC ve OAuth 2.0 kullanması gerektiğini, bunlara ne zaman ihtiyaç duymayabileceğini ve gerçek bir iş kuruyorsanız ve bir CIAM çözümü seçiyorsanız bu açık standartları en baştan benimsemenin neden önemli olduğunu açıklayacağım. Ayrıca AI'nın yükselişinin bu kararı neden her zamankinden daha önemli hale getirdiğini de açıklayacağım.
OAuth 2.0 ile çok tanıdık olmayan okuyucular için, bazı temel kavramları tekrar açıklamak için kısa bir süre ayırayım - sadece işleri daha net hale getirmek için.
OAuth 2.0, yetkilendirme devri içindir: OAuth 2.0, bir hizmetin kaynak sahibinin rızasıyla başka bir hizmetin adına kaynaklara erişmesine izin veren endüstri standardı bir yetkilendirme protokolüdür.
Bir OAuth senaryosunda, kullanıcı (kaynak sahibi) bir istemci uygulamaya, parolasını paylaşmadan bir API veya kaynak sunucusuna sınırlı erişim (belirli izinler) verir. OAuth, istemcinin korunan API'leri çağırmak için kullanabileceği erişim belirteçlerinin nasıl talep edilip verileceğini tanımlar. Bu, uygulamaların başka bir hizmete erişim sağlamak için kimlik bilgilerinizi isteyebileceği eski günlerdeki ciddi güvenlik riskine kıyasla oyunu değiştirdi. OAuth 2.0 ile kullanıcılar belirli bir erişimi onaylar ve istemci yalnızca gerekli izin ve süreyi içeren bir belirteç alır - hiçbir parola paylaşılmaz, bu da güvenliği önemli ölçüde artırır.
OAuth 2.0'ı bir otele giriş yapmak gibi düşünün.
Siz (kullanıcı) odanın sahibi (verilerinizsiniz). Ancak birine oda anahtarınızı (parolanız) vermek yerine, ön büroya gidip sadece misafirinizin veya arkadaşınızın spor salonuna veya havuza girmesine izin veren (bir erişim belirteci) geçici bir erişim kartı istersiniz — tüm odaya değil.
Otel çalışanları (OAuth sistemi) bu sınırlı kartı belirli kurallarla düzenler:
Yalnızca spor salonu için çalışır (belirli kaynak).
Kısa bir süre için geçerlidir.
Hiç kimse odanıza giremez.
Bu şekilde, ana anahtarınızı vermeniz gerekmez ve sistem, bu sınırlı kart başkasının eline geçse bile güvenli kalır.
Başka bir örneğe bakalım. OAuth 2.0, sosyal giriş senaryosunda yaygın olarak kullanılır.
Diyelim ki Notion gibi yeni bir uygulamaya kaydoluyorsunuz ve yeni bir kullanıcı adı ve şifre oluşturmak yerine “Google ile Devam Et” butonuna tıklıyorsunuz.
İşte OAuth 2.0 ile perde arkasında neler oluyor:
Google'ın giriş sayfasına yönlendirilirsiniz ve burada oturum açarsınız (henüz oturum açmadıysanız).
Google sorar:
“Bu uygulamanın temel profilinizi ve e-posta adresinizi görmesine izin veriyor musunuz?”
“İzin Ver” butonuna tıklarsınız ve Google uygulamaya bir erişim belirteci gönderir.
Uygulama bu belirteci kullanarak:
Sizin kimliğinizi doğrular (e-posta ve profil bilginiz aracılığıyla).
Apple veya Google şifrenizi hiç görmeden bir hesap oluşturur veya sizi oturum açtırır.
Şimdi OIDC'ye bakalım — daha yeni ve daha gelişmiş bir standart. OpenID Connect, Kimlik ve Kimlik Doğrulama için hedeflenmiştir: OAuth 2.0’ın üzerine inşa edilmiş bir kimlik doğrulama katmanıdır. OAuth 2.0 yalnızca erişim belirteçleri ve kapsamlarla ilgilenirken, OIDC, kullanıcı girişi ve kimliğini standart bir şekilde ele almak için bir yöntem ekler.
OIDC kullanılırken yetkilendirme sunucusu ayrıca bir OpenID Sağlayıcısı (kimlik sağlayıcısı) olarak hareket eder, kullanıcıyı doğrular ve kullanıcı hakkında bilgi içeren bir ID belirteci (kimlik iddiaları) verir.
Kısacası, OAuth 2.0, “Bu istemci bu kaynağa erişebilir mi?” sorusunu yanıtlar ve OIDC “Giriş yapmış olan kullanıcı kim?” sorusunu yanıtlar. Birlikte çalışarak uygulamanızın kullanıcının kimliğini doğrulamasına ve ardından kullanıcı adına API'lere erişim sağlaması için yetkilendirilmiş belirteçler kullanmasına izin verirler.
OAuth 2.0 ve OIDC'yi Tekrar Daha İyi Anlamak İçin Otel Benzerliğini Kullanalım.
Bir otele giriş yaptığınızı hayal edin.
OAuth 2.0 sizin adınıza arkadaşınızın spor salonu ve havuzu kullanmasını otelden istemek gibidir.
Ön büroya gidip izin verirsiniz ve otel arkadaşınıza bir misafir geçişi verir.
Otel, arkadaşınızın kim olduğu konusunda önem taşımaz — sadece tesisleri kullanmasına izin verildiğiyle ilgilenir.
👉 Bu OAuth: “Bu uygulama verilerime veya hizmetlerime erişebilir.”
OIDC misafire erişim vermeden önce kişinin kim olduğunu otelden kontrol etmesini istemek gibidir.
Arkadaşınız bir kimlik kartı da gösterir — ve şimdi otel, onun adını, durumunu ve onaylanmış bir misafir olduğunu bilir.
👉 Bu OIDC: “İşte kullanıcı kim, ve şimdi giriş yaptı.”
Logto OAuth 2.0 ve OpenID Connect (OIDC)'yi Nasıl Kullanır#
Logto'nun temel kimlik doğrulama özellikleri, OIDC (OpenID Connect) üzerine inşa edilmiştir#
Temelinde, Logto bir OpenID Connect (OIDC) sağlayıcısıdır — güvenli, modern kullanıcı kimlik doğrulamaya odaklanan OAuth 2.0 üzerine inşa edilmiş bir standarttır. Logto, kimliklerin yönetildiği profesyonel bir CIAM çözümüdür.
Logto’yu güvenliği temel olarak tasarladık. Bu da varsayılan olarak PKCE'nin uygulanması, gizli akış gibi güvensiz akışların engellenmesi ve güvenli bir şekilde oturum açma işlemlerini yönetmek için yönlendirmeye dayanmak anlamına geliyor.
OIDC tarayıcı tabanlı kimlik doğrulama için tasarlanmıştır. Bu sadece teknik bir seçim değildir — kullanıcılara platformlar arasında güvenli ve tutarlı bir deneyim sunmakla ilgilidir. Kullanıcıyı kimlik sağlayıcıya (Logto, Google veya Microsoft gibi) yönlendirmek bunu mümkün kılmaya yardımcı olur.
Ve eğer ürününüz birden fazla uygulamayı kapsıyorsa, Yönlendirme tek oturum açma sağlar — kullanıcılar bir kez oturum açar ve uygulamalar arasında sorunsuzca geçiş yapar.
Logto'da doğrudan uygulamanızda şifre toplamak desteklenmez. Bu kasıtlıdır. ROPC akışıOAuth 2.0 güvenlik en iyi uygulamaları için önerilmez — daha az güvenli ve güvenli bir şekilde ölçeklenmesi zordur.
Logto ayrıca bir OAuth 2.0/OIDC sağlayıcıdır (Kimlik Sağlayıcı)#
Logto sadece bir kimlik doğrulama sunucusu değil — aynı zamanda tam bir OAuth 2.0, OpenID Connect (OIDC) ve Kimlik Sağlayıcıdır (IdP). Bu, kullanıcı kimliklerini güvenli bir şekilde yönetebileceği ve diğer uygulamaların güvenebileceği belirteçler yayınlayabileceği anlamına gelir.
Kendi uygulamalarınız için oturum açma deneyimlerinin güçlendirilmesinin yanı sıra Logto, üçüncü taraf uygulama entegrasyonlarını da destekler ve dış hizmetlerin Logto'yu kimlik kaynağı olarak kullanmasına izin verir.
Bu pratikte ne anlama gelir?
Bir Kimlik Sağlayıcı (IdP) olarak, Logto kullanıcı doğrulamasını yapar, kimlik bilgilerini yönetir ve kimlik doğrulama belirteçleri yayınlar. Kullanıcı oturum açtığında, Logto onları farklı uygulamalara erişim izni verir — hatta diğer satıcılardan — tekrar oturum açma gereği olmadan. Bu, “Google ile Oturum Aç” veya “Microsoft ile Oturum Aç” arkasındaki aynı konsepttir.
Bu bağlamda iki tür uygulama vardır:
Birinci taraf uygulamalar: Logto ile doğrudan entegre edilmiş, tam sizin kontrolünüzde olan uygulamalar.
Üçüncü taraf uygulamalar: Kuruluşunuz dışındaki ortaklar veya geliştiriciler tarafından oluşturulan dış hizmetler.
Logto, kullanıcılarınızın var olan Logto hesaplarını kullanarak bu üçüncü taraf uygulamalara giriş yapmasına izin verir — aynı bir şirket kullanıcısının Slack gibi araçlara Google Workspace kimlik bilgilerini kullanarak girmesi gibi. Bu, sizin için şunları sağlar:
Ekosisteminiz genelinde tek tuşla oturum açma (SSO) sunmak.
Üçüncü taraf geliştiricilerin uygulamalarına “Logto ile Oturum Aç” ekleyebileceği bir açık platform oluşturmak.
Gerçekten Ne Zaman OAuth 2.0 ve OIDC'ye ihtiyacınız var?#
Daha önce Auth0 (veya benzeri) kullandıysanız: Auth0 zaten bir OAuth 2.0 ve OIDC sağlayıcısıdır. Kullanıcı girişlerini yönetir, belirteç verir ve API’leriniz veya uygulamalarınızla entegre olur.
M2M yetkilendirme: Sunucu-sunucu (istemci kimlik bilgileri akışı)
Makineler (veya arka plan hizmetleri) bir kullanıcı olmadan güvenli bir şekilde iletişim kurmalıdır.
Cihaz akışı: Akıllı TV’ler, konsollar, IoT cihazları: TV veya yazıcı gibi cihazların bir kullanıcıyı doğrulaması gerekir. Cihaz akışı OIDC'nin bir parçasıdır.
Etkileşim ihtiyaçlarınız varsa: Sadece kullanıcıları doğrulamıyorsunuz — ayrıca dış uygulamalar, ortaklar veya ajanların platformunuzla entegre olabileceği ve kullanıcı verilerine güvenli bir şekilde erişebileceği bir ekosistem oluşturuyorsunuz.
AI Çağında OAuth ve OIDC'nin Daha Önemli Olmasının Nedenleri#
AI çağında, özellikle otonom ajanlar, akıllı cihazlar ve sistemler arası iletişim gibi alanlarda yeni entegrasyon ve erişim ihtiyaçlarında bir artış görüyoruz. Bu trendler, OAuth 2.0 ve OIDC'yi her zamankinden daha önemli hale getiriyor. İşte birkaç örnek:
Uzaktan MCP sunucuları
Uzaktan bir MCP (Model Context Protocol) sunucusu inşa ediyorsunuz ve üçüncü taraf ajanlarının ona bağlanmasını istiyorsunuz. Bu ajanlar, bağlam talep etmek, eylemler gerçekleştirmek ve veri alışverişi yapmak için güvenli erişime ihtiyaç duyarlar — hepsi kullanıcı güvenliğini tehlikeye atmadan. OAuth, erişimi güvenli bir şekilde devretmenin mekanizmasını sağlar.
Ürününüzü entegrasyonlara açmak
Kendi iş hizmetlerinizi yürütüyorsunuz — diyelim ki bir proje yönetim aracı veya bir müşteri platformu — ve diğer ürün veya ajanlarla entegre olmasını istiyorsunuz. Bu, veri çekmek, iş akışlarını başlatmak veya özelliklerinizi başka ortamlara yerleştirmek anlamına gelebilir. OAuth 2.0/OIDC kullanıcı kimlik bilgilerini paylaşmadan ayrıntılı, belirteç tabanlı erişim kontrolünü etkinleştirir.
Kendi ajanınzı oluşturmak
Bir AI ajanı veya asistanı oluşturuyorsunuz ve diğer uygulamalar ve MCP sunucularıyla etkileşimde bulunmasını istiyorsunuz — toplantıları planlama, e-postalar gönderme, güncellemeler gönderme veya veri sorgulama. Bunlar, üçüncü taraf hizmetlere güvenli, kimliği doğrulanmış erişim gerektirir. OAuth 2.0, ajanın kullanıcı adına hareket etmesi için nasıl yetkilendirileceğini sağlar.
Akıllı cihazların yükselişi
AI çevirmenler veya akıllı toplantı not alıcıları gibi donanım cihazları LLM'ler sayesinde daha yetenekli hale geliyor. Düşük maliyet ve yüksek performans ile daha fazla cihaz piyasaya çıkıyor. Bu cihazlar genellikle kullanıcıları kimlik doğrulama ve bulut tabanlı hizmetlere erişim sağlama yolunu bulmaları gerekiyor — özellikle sınırlı giriş arayüzlerinde. OAuth'un cihaz yetkilendirme akışı ve OIDC tabanlı kimlik doğrulama bu noktada kritik hale geliyor.
Belki de OAuth 2.0/OIDC'ye İhtiyacınız Olmadığı Durumlar#
Elbette, OAuth 2.0 veya OIDC'ye ihtiyaç duymadığınız durumlar da vardır — en azından şu anda. Başka bir deyişle, eğer mevcut kullanım durumunuz basit veya tamamen kendi içinde ise, bu protokoller hemen bir değer sağlamayabilir.
Bununla birlikte, ürününüz büyüdükçe veya ekosisteminiz genişledikçe, OAuth 2.0 ve OIDC'ye olan ihtiyaç genellikle uzun vadede çok daha net hale gelir.
Basit, iç uygulamalar
Eğer uygulama sadece bir şirket içindeki küçük bir ekip tarafından kullanılıyorsa ve üçüncü taraf hizmetler ile entegre olmuyorsa veya API'leri açmıyorsa, temel bir kullanıcı adı-şifre kimlik doğrulama sistemi (ör. çerez oturumları) yeterli olabilir.
Ürününüzde kullanıcı hesapları veya kimlik farkındalığı sağlayan özellikler yoksa — örneğin bir halka açık içerik sitesi veya statik API anahtarları ile çalışan sunucu-sunucu araç — OIDC gerekmez.
Yetkilendirilmiş erişim gerekmediği durumlar
OAuth, kullanıcıların uygulamanıza başka bir sistemdeki verilerine erişim izni vermesi gerektiğinde parlamaktadır (ör. Google Drive). Üçüncü taraf API'leriyle entegre olmuyorsanız veya çoklu hizmet iş akışları oluşturmuyorsanız, OAuth karmaşıklık ekler ve biraz değer sunar.
Tek ortam, minimal risk
Erken dönem prototipleri, MVP'ler veya iç test araçları için basitlik ve hız güvenlik ihtiyaçlarının önündeyse, OAuth/OIDC'yi geleceğe ertelemek isteyebilirsiniz.
Doğru Yetkilendirme Stratejisini Seçme Üzerine Son Düşünceler#
Hemen OAuth 2.0 veya OIDC'ye ihtiyacınız olmayabilir — ve bu tamamen normaldir. İlk aşamalarda, basit çözümler genellikle işi halleder. Ancak ürününüz büyüdükçe, ajanlar ve AI'nın entegrasyonu arttıkça ve ekosisteminiz ortaklara ve üçüncü taraflara açıldıkça, güvenli ve standartlara uygun kimlik doğrulama bir hoşluk olmaktan çıkar ve bir gereklilik haline gelir.
Sonradan yetişmeye çalışmak yerine, şimdi temelleri atmak mantıklıdır. OAuth 2.0 ve OIDC'yi benimsemek sadece bugünün sorunlarını çözmekle ilgili değil — yarın karşılaşacaklarınız için hazır olmaktır.
