Modern uygulamalarda kullan\u0131c\u0131 kimlik do\u011frulama s\u00fcre\u00e7leri karma\u015f\u0131kla\u015f\u0131yor mu? SAML ve OIDC aras\u0131ndaki temel farklar\u0131, avantajlar\u0131n\u0131, dezavantajlar\u0131n\u0131 ve uygulaman\u0131za en uygun kimlik do\u011frulama protokol\u00fcn\u00fc nas\u0131l se\u00e7ece\u011finizi bu kapsaml\u0131 rehberde ke\u015ffedin. G\u00fcvenli ve sorunsuz bir deneyim i\u00e7in do\u011fru ad\u0131m\u0131 at\u0131n.<\/p>\n
G\u00fcn\u00fcm\u00fcz dijital d\u00fcnyas\u0131nda, kullan\u0131c\u0131lar\u0131n birden fazla uygulama ve servisle etkile\u015fim kurmas\u0131 ka\u00e7\u0131n\u0131lmaz hale gelmi\u015ftir. Bir yandan e-posta uygulaman\u0131za giri\u015f yaparken, di\u011fer yandan bir bulut depolama hizmetine eri\u015fmeniz veya farkl\u0131 bir i\u015f uygulamas\u0131na ge\u00e7i\u015f yapman\u0131z gerekebilir. Her seferinde ayr\u0131 ayr\u0131 kullan\u0131c\u0131 ad\u0131 ve \u015fifre girmek, hem kullan\u0131c\u0131 deneyimini olumsuz etkiler hem de g\u00fcvenlik risklerini art\u0131r\u0131r. \u0130\u015fte bu noktada, “tek oturum a\u00e7ma” (Single Sign-On – SSO) kavram\u0131 devreye girer. SSO, kullan\u0131c\u0131lar\u0131n bir kez kimlik do\u011frulamas\u0131ndan ge\u00e7tikten sonra, yetkili olduklar\u0131 t\u00fcm uygulamalara ek bir kimlik do\u011frulamas\u0131na gerek kalmadan eri\u015febilmelerini sa\u011flayan bir mekanizmad\u0131r. Ancak SSO’yu sa\u011flamak, sand\u0131\u011f\u0131n\u0131z kadar basit de\u011fildir. Farkl\u0131 uygulamalar\u0131n, farkl\u0131 platformlar\u0131n ve farkl\u0131 g\u00fcvenlik gereksinimlerinin oldu\u011fu bir ortamda, bu entegrasyonu g\u00fcvenli ve verimli bir \u015fekilde ger\u00e7ekle\u015ftirmek i\u00e7in standart protokollere ihtiya\u00e7 duyar\u0131z. Bu protokollerden en yayg\u0131n ve etkili olanlar\u0131 ise G\u00fcvenlik Onaylama \u0130\u015faretleme Dili (Security Assertion Markup Language – SAML) ve A\u00e7\u0131k Kimlik Ba\u011flant\u0131s\u0131 (OpenID Connect – OIDC) olarak \u00f6ne \u00e7\u0131kar. Peki, bu iki g\u00fc\u00e7l\u00fc protokol aras\u0131ndaki farklar nelerdir ve uygulaman\u0131z i\u00e7in do\u011fru se\u00e7imi nas\u0131l yapmal\u0131s\u0131n\u0131z? Bu makale, sizi s\u0131f\u0131rdan ba\u015flayarak bu karma\u015f\u0131k d\u00fcnyada ad\u0131m ad\u0131m ilerletecek, her iki protokol\u00fcn de temellerini, \u00e7al\u0131\u015fma prensiplerini, avantajlar\u0131n\u0131, dezavantajlar\u0131n\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l kullan\u0131ld\u0131\u011f\u0131n\u0131 detayl\u0131 bir \u015fekilde a\u00e7\u0131klayacakt\u0131r. Amac\u0131m\u0131z, uygulaman\u0131z\u0131n gelece\u011fini g\u00fcvence alt\u0131na al\u0131rken, geli\u015ftirici ekibinizin i\u015f y\u00fck\u00fcn\u00fc de hafifletecek en uygun karar\u0131 vermenize yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n
Kimlik do\u011frulama protokollerinin derinliklerine inmeden \u00f6nce, baz\u0131 temel kavramlar\u0131 netle\u015ftirmek faydal\u0131 olacakt\u0131r. Bu kavramlar, SAML ve OIDC’nin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak i\u00e7in hayati \u00f6neme sahiptir. \u0130lk olarak, “kimlik do\u011frulama” (authentication) ile “yetkilendirme” (authorization) aras\u0131ndaki fark\u0131 kavramakla ba\u015flayal\u0131m. Kimlik do\u011frulama, bir kullan\u0131c\u0131n\u0131n ger\u00e7ekten iddia etti\u011fi ki\u015fi olup olmad\u0131\u011f\u0131n\u0131 do\u011frulama s\u00fcrecidir. Genellikle kullan\u0131c\u0131 ad\u0131 ve \u015fifre kombinasyonu, biyometrik veriler veya tek kullan\u0131ml\u0131k kodlarla ger\u00e7ekle\u015ftirilir. \u00d6rne\u011fin, e-posta adresiniz ve \u015fifrenizle Gmail’e giri\u015f yapt\u0131\u011f\u0131n\u0131zda, kimli\u011finiz do\u011frulanm\u0131\u015f olur. Yetkilendirme ise, kimli\u011fi do\u011frulanm\u0131\u015f bir kullan\u0131c\u0131n\u0131n belirli bir kayna\u011fa veya i\u015fleme eri\u015fim izni olup olmad\u0131\u011f\u0131n\u0131 belirleme s\u00fcrecidir. Yani, Gmail’e giri\u015f yapt\u0131ktan sonra gelen kutunuza bakma izniniz varsa bu bir yetkilendirmedir, ancak Drive’\u0131n\u0131zdaki t\u00fcm dosyalar\u0131 silme izniniz olmayabilir. SAML ve OIDC daha \u00e7ok kimlik do\u011frulama ve kimlik bilgisinin g\u00fcvenli bir \u015fekilde aktar\u0131lmas\u0131na odaklan\u0131r, ancak OIDC, \u00f6zellikle OAuth 2.0 ile birlikte kullan\u0131ld\u0131\u011f\u0131nda yetkilendirme ak\u0131\u015flar\u0131n\u0131n da bir par\u00e7as\u0131 haline gelir.<\/p>\n
\u0130kinci temel ta\u015f\u0131m\u0131z ise SSO’nun mimarisidir. SSO \u00e7\u00f6z\u00fcmlerinde genellikle iki ana rol bulunur:<\/p>\n
Bu iki taraf aras\u0131ndaki g\u00fcvenli ileti\u015fimi sa\u011flamak i\u00e7in protokoller devreye girer. Protokoller, kimlik bilgilerinin (veya bu bilgileri i\u00e7eren token’lar\u0131n) nas\u0131l formatlanaca\u011f\u0131n\u0131, nas\u0131l \u015fifrelenece\u011fini ve hangi ad\u0131mlarla aktar\u0131laca\u011f\u0131n\u0131 standartla\u015ft\u0131r\u0131r. Bu sayede, farkl\u0131 firmalar taraf\u0131ndan geli\u015ftirilen IdP’ler ve SP’ler sorunsuz bir \u015fekilde birbiriyle ileti\u015fim kurabilir. Bu sayede kullan\u0131c\u0131lar, tek bir kimlik bilgisi setiyle birden fazla uygulamaya g\u00fcvenle eri\u015febilirler. \u0130\u015fte bu temel yap\u0131n\u0131n anla\u015f\u0131lmas\u0131, SAML ve OIDC’nin karma\u015f\u0131k gibi g\u00f6r\u00fcnen d\u00fcnyas\u0131na girerken bize sa\u011flam bir zemin haz\u0131rlayacakt\u0131r. \u0130lerleyen b\u00f6l\u00fcmlerde, bu iki protokol\u00fcn bu \u00e7er\u00e7eve i\u00e7inde nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve hangi senaryolarda daha uygun olduklar\u0131n\u0131 detayl\u0131ca inceleyece\u011fiz.<\/p>\n
Security Assertion Markup Language (SAML), \u00f6zellikle kurumsal d\u00fcnyada uzun y\u0131llard\u0131r kullan\u0131lan k\u00f6kl\u00fc bir kimlik do\u011frulama protokol\u00fcd\u00fcr. 2000’li y\u0131llar\u0131n ba\u015f\u0131nda ortaya \u00e7\u0131kan SAML, XML tabanl\u0131 mesajla\u015fma yap\u0131s\u0131 sayesinde, farkl\u0131 g\u00fcvenlik alanlar\u0131 aras\u0131nda kimlik do\u011frulama ve yetkilendirme verilerini g\u00fcvenli bir \u015fekilde de\u011fi\u015ftirmek i\u00e7in tasarlanm\u0131\u015ft\u0131r. Genellikle b\u00fcy\u00fck \u00f6l\u00e7ekli \u015firketler, intranet uygulamalar\u0131 ve bulut tabanl\u0131 kurumsal hizmetler (SaaS) aras\u0131nda SSO sa\u011flamak amac\u0131yla kullan\u0131l\u0131r. \u00d6rne\u011fin, bir \u00e7al\u0131\u015fan Microsoft 365’e veya Salesforce’a kendi \u015firket kimlik bilgileriyle giri\u015f yaparken arka planda genellikle SAML protokol\u00fc \u00e7al\u0131\u015f\u0131r.<\/p>\n
SAML’\u0131n temel \u00e7al\u0131\u015fma prensibi, bir kullan\u0131c\u0131n\u0131n kimli\u011fini do\u011frulayan bir IdP ile kullan\u0131c\u0131n\u0131n eri\u015fmek istedi\u011fi bir SP aras\u0131nda g\u00fcven ili\u015fkisi kurmakt\u0131r. Bu s\u00fcre\u00e7 genellikle \u015fu ad\u0131mlar\u0131 izler:<\/p>\n
Bu ak\u0131\u015f sayesinde, kullan\u0131c\u0131 sadece IdP’ye kimlik bilgilerini vermekle kal\u0131r ve IdP ile SP aras\u0131ndaki g\u00fcven ili\u015fkisi, hassas bilgilerin SP’ye do\u011frudan aktar\u0131lmas\u0131n\u0131 gerektirmez.<\/p>\n
SAML’\u0131n Avantajlar\u0131:<\/strong><\/p>\n SAML’\u0131n Dezavantajlar\u0131:<\/strong><\/p>\n Vaka Analizi: Kurumsal Bir Uygulama Entegrasyonu<\/strong><\/p>\n B\u00fcy\u00fck bir finans kurulu\u015fu olan “FinansTech”, i\u00e7 operasyonlar\u0131 i\u00e7in birden fazla SaaS (Software as a Service) uygulamas\u0131 kullanmaktad\u0131r (CRM, ERP, \u0130K Y\u00f6netimi). Her uygulamaya ayr\u0131 ayr\u0131 giri\u015f yapmak, \u00e7al\u0131\u015fanlar i\u00e7in hem zaman kayb\u0131 yaratmakta hem de \u015fifre y\u00f6netimini zorla\u015ft\u0131rmaktayd\u0131. FinansTech, mevcut Active Directory tabanl\u0131 kimlik y\u00f6netim sistemlerini IdP olarak kullanarak t\u00fcm SaaS uygulamalar\u0131n\u0131 SAML ile entegre etmeye karar verdi. Bu sayede, \u00e7al\u0131\u015fanlar \u015firketin intranetine bir kez giri\u015f yapt\u0131ktan sonra, t\u00fcm di\u011fer kurumsal uygulamalara ek kimlik do\u011frulamas\u0131na gerek kalmadan eri\u015febilmekteydi. Bu \u00e7\u00f6z\u00fcm, kullan\u0131c\u0131 deneyimini iyile\u015ftirirken, IT y\u00f6neticileri i\u00e7in de merkezi kullan\u0131c\u0131 y\u00f6netimi avantaj\u0131 sa\u011flad\u0131.<\/p>\n <\/code><\/p>\n Yukar\u0131daki \u00f6rnek, bir Servis Sa\u011flay\u0131c\u0131'n\u0131n Kimlik Sa\u011flay\u0131c\u0131'ya g\u00f6nderdi\u011fi basit bir kimlik do\u011frulama iste\u011fini g\u00f6sterir. Bu XML yap\u0131s\u0131, iste\u011fin kimden geldi\u011fini (Issuer), hangi adrese geri d\u00f6n\u00fclmesi gerekti\u011fini (AssertionConsumerServiceURL) ve di\u011fer \u00f6nemli parametreleri i\u00e7erir.<\/p>\n OpenID Connect (OIDC), OAuth 2.0 yetkilendirme \u00e7er\u00e7evesinin \u00fczerine in\u015fa edilmi\u015f, basit ve modern bir kimlik do\u011frulama katman\u0131d\u0131r. 2014 y\u0131l\u0131nda yay\u0131nlanan OIDC, SAML'\u0131n kurumsal odakl\u0131l\u0131\u011f\u0131n\u0131n aksine, \u00f6zellikle mobil uygulamalar, tek sayfa uygulamalar (SPA), API'ler ve genel t\u00fcketici odakl\u0131 web hizmetleri i\u00e7in tasarlanm\u0131\u015ft\u0131r. OIDC'nin pop\u00fclaritesi, JSON Web Token (JWT) tabanl\u0131 yap\u0131s\u0131 ve RESTful API'lerle do\u011fal uyumu sayesinde h\u0131zla artm\u0131\u015ft\u0131r. Google, Facebook, Microsoft ve Apple gibi devler, kendi kimlik do\u011frulama servislerinde OIDC'yi aktif olarak kullanmaktad\u0131r.<\/p>\n OIDC, temelinde OAuth 2.0'\u0131 kullan\u0131r, ancak OAuth 2.0'dan farkl\u0131 olarak sadece yetkilendirme de\u011fil, ayn\u0131 zamanda kimlik do\u011frulama da sa\u011flar. OAuth 2.0 \"izin\" vermeye odaklan\u0131rken, OIDC \"kim oldu\u011funu s\u00f6yle\" sorusuna yan\u0131t verir. OIDC'nin \u00e7al\u0131\u015fma ak\u0131\u015f\u0131 genellikle \"Authorization Code Flow\" (Yetkilendirme Kodu Ak\u0131\u015f\u0131) ile ger\u00e7ekle\u015fir ve a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 i\u00e7erir:<\/p>\n ID Token (JWT):<\/strong> Bu, kullan\u0131c\u0131n\u0131n kimli\u011fi hakk\u0131nda temel bilgileri (\u00f6rne\u011fin, kullan\u0131c\u0131 ID'si, ad\u0131, e-posta adresi) i\u00e7eren, dijital olarak imzalanm\u0131\u015f bir JSON Web Token'd\u0131r (JWT). JWT'ler \u00fc\u00e7 ana b\u00f6l\u00fcmden olu\u015fur: Ba\u015fl\u0131k (Header), Y\u00fck (Payload) ve \u0130mza (Signature). \u00d6zellikle hafif yap\u0131s\u0131 ve kolay ayr\u0131\u015ft\u0131r\u0131labilirli\u011fi sayesinde modern uygulamalar i\u00e7in idealdir.<\/p>\n Access Token:<\/strong> Bu, kullan\u0131c\u0131n\u0131n belirli kaynaklara (\u00f6rne\u011fin, API'ler) eri\u015fim yetkilerini temsil eden bir jetondur. Genellikle bir opaque string (saydam bir dizi) veya ba\u015fka bir JWT olabilir. Client, bu token'\u0131 yetkilendirilmi\u015f isteklere ekleyerek kaynak sunucular\u0131na g\u00f6nderir.<\/p>\n OIDC'nin Avantajlar\u0131:<\/strong><\/p>\n OIDC'nin Dezavantajlar\u0131:<\/strong><\/p>\n <\/code><\/p>\n Yukar\u0131daki JSON yap\u0131s\u0131, OIDC ID Token'\u0131n\u0131n \u015fifresi \u00e7\u00f6z\u00fcld\u00fc\u011f\u00fcnde ortaya \u00e7\u0131kan kullan\u0131c\u0131 bilgilerini (payload) g\u00f6sterir. 'iss' kimlik sa\u011flay\u0131c\u0131y\u0131, 'sub' kullan\u0131c\u0131 kimli\u011fini, 'email' kullan\u0131c\u0131n\u0131n e-postas\u0131n\u0131 ve 'exp' token'\u0131n ge\u00e7erlilik s\u00fcresinin sonunu belirtir.<\/p>\n Vaka Analizi: Modern Mobil Uygulama ve API Entegrasyonu<\/strong><\/p>\n \"MobilBank\" adl\u0131 yeni nesil bir mobil bankac\u0131l\u0131k uygulamas\u0131, kullan\u0131c\u0131lar\u0131n\u0131n mevcut banka hesaplar\u0131yla g\u00fcvenli bir \u015fekilde entegre olmas\u0131n\u0131 ve di\u011fer finansal hizmetlere eri\u015fmesini sa\u011flamak istiyordu. Uygulama, kullan\u0131c\u0131lar\u0131n kolayca kay\u0131t olabilmesi ve giri\u015f yapabilmesi i\u00e7in Google, Apple ve di\u011fer finansal hizmet sa\u011flay\u0131c\u0131lar\u0131n\u0131n OIDC tabanl\u0131 kimlik do\u011frulama API'lerini kullanmay\u0131 tercih etti. Bu sayede, kullan\u0131c\u0131lar mevcut kimlik bilgileriyle h\u0131zl\u0131ca giri\u015f yapabilirken, MobilBank uygulamas\u0131 da kullan\u0131c\u0131 ad\u0131na di\u011fer API'lere (hesap bilgileri, i\u015flem ge\u00e7mi\u015fi vb.) eri\u015fmek i\u00e7in Access Token'lar\u0131 g\u00fcvenli bir \u015fekilde kullanabilmekteydi. OIDC'nin hafif yap\u0131s\u0131 ve mobil entegrasyon kolayl\u0131\u011f\u0131 sayesinde, geli\u015ftirme s\u00fcreci h\u0131zland\u0131 ve uygulama, milyonlarca kullan\u0131c\u0131ya sorunsuz bir deneyim sunabildi.<\/p>\n SAML ve OIDC'nin her ikisi de tek oturum a\u00e7ma (SSO) \u00e7\u00f6z\u00fcmleri sunsa da, alt\u0131nda yatan teknoloji, kullan\u0131m senaryolar\u0131 ve felsefeleri \u00f6nemli \u00f6l\u00e7\u00fcde farkl\u0131l\u0131k g\u00f6sterir. \u0130\u015fte temel farklar\u0131 \u00f6zetleyen bir kar\u015f\u0131la\u015ft\u0131rma tablosu:<\/p>\n Bu farklar, uygulaman\u0131z\u0131n do\u011fas\u0131na ve hedeflenen kullan\u0131m senaryolar\u0131na ba\u011fl\u0131 olarak hangi protokol\u00fcn daha uygun olaca\u011f\u0131n\u0131 belirlemede kritik rol oynar.<\/p>\n SAML ve OIDC aras\u0131ndaki farklar\u0131 anlad\u0131ktan sonra, belki de en kritik soruya geliyoruz: \"Benim uygulamam i\u00e7in hangisi do\u011fru se\u00e7im?\" Bu karar, uygulaman\u0131z\u0131n mimarisi, hedef kitlesi, mevcut altyap\u0131n\u0131z ve hatta geli\u015ftirici ekibinizin deneyimi gibi bir\u00e7ok fakt\u00f6re ba\u011fl\u0131d\u0131r. \u0130\u015fte size bu karar\u0131 verirken yol g\u00f6sterecek baz\u0131 sorular ve senaryolar:<\/p>\n Vaka Analizi: Hibrit Bir \u015eirket Mimarisi<\/strong><\/p>\n \"GlobalTech\" adl\u0131 uluslararas\u0131 bir teknoloji \u015firketi, hem binlerce \u00e7al\u0131\u015fan\u0131n\u0131n kulland\u0131\u011f\u0131 \u015firket i\u00e7i sistemlere hem de milyonlarca m\u00fc\u015fteriye hizmet veren mobil uygulamalara sahipti. \u015eirket i\u00e7i sistemler y\u0131llard\u0131r SAML tabanl\u0131 bir Active Directory Federasyon Hizmetleri (ADFS) ile entegreydi. Yeni geli\u015ftirilen m\u00fc\u015fteri odakl\u0131 mobil uygulamalar i\u00e7in ise ADFS'nin karma\u015f\u0131kl\u0131\u011f\u0131 ve XML yap\u0131s\u0131 uygun de\u011fildi. GlobalTech, bu durumda hibrit bir yakla\u015f\u0131m benimsedi: Mevcut SAML altyap\u0131s\u0131n\u0131 koruyarak i\u00e7 sistemlerde SSO sa\u011flamaya devam etti. Yeni mobil uygulamalar ve API'ler i\u00e7in ise Okta gibi modern bir Kimlik Sa\u011flay\u0131c\u0131'y\u0131 kullanarak OIDC tabanl\u0131 kimlik do\u011frulama entegrasyonunu tercih etti. Okta hem SAML hem de OIDC'yi destekleyebildi\u011finden, farkl\u0131 ihtiya\u00e7lar\u0131 olan uygulamalar i\u00e7in tek bir merkezi kimlik y\u00f6netimi noktas\u0131 olu\u015fturulabildi. Bu strateji, hem kurumsal g\u00fcvenlik standartlar\u0131n\u0131 s\u00fcrd\u00fcrd\u00fc hem de modern geli\u015ftirme s\u00fcre\u00e7lerini h\u0131zland\u0131rd\u0131.<\/p>\n SAML ve OIDC'nin temellerini ve se\u00e7im kriterlerini anlad\u0131k. \u015eimdi, bu protokolleri daha etkin ve g\u00fcvenli bir \u015fekilde kullanman\u0131z\u0131 sa\u011flayacak baz\u0131 ileri d\u00fczey konulara ve en iyi uygulamalara de\u011finelim.<\/p>\n OIDC'nin kalbinde yer alan JWT'ler, basit ve hafif olmalar\u0131na ra\u011fmen, do\u011fru kullan\u0131lmad\u0131\u011f\u0131nda g\u00fcvenlik riskleri ta\u015f\u0131yabilir. \u0130\u015fte dikkat etmeniz gerekenler:<\/p>\n Her iki protokol de belirli d\u00fczeyde geni\u015fletilebilirli\u011fe sahiptir:<\/p>\n Mikro hizmet mimarilerinde veya birden fazla arka u\u00e7 servisi olan uygulamalarda, bir API Gateway kullanmak kimlik do\u011frulama y\u00f6netimini merkezile\u015ftirmek i\u00e7in harika bir yakla\u015f\u0131md\u0131r. API Gateway, gelen isteklerin kimlik do\u011frulamas\u0131n\u0131 (hem SAML hem de OIDC token'lar\u0131n\u0131 do\u011frulayabilir) ve yetkilendirmesini yaparak arka u\u00e7 servislerine sadece g\u00fcvenli isteklerin ula\u015fmas\u0131n\u0131 sa\u011flar. Bu sayede her mikro hizmetin kendi kimlik do\u011frulama mant\u0131\u011f\u0131n\u0131 uygulamas\u0131na gerek kalmaz.<\/p>\n G\u00fcn\u00fcm\u00fczde sadece tek fakt\u00f6rl\u00fc (kullan\u0131c\u0131 ad\u0131\/\u015fifre) kimlik do\u011frulama yeterli de\u011fildir. Hem SAML hem de OIDC, MFA (\u00c7ok Fakt\u00f6rl\u00fc Kimlik Do\u011frulama) entegrasyonuna izin verir. Genellikle MFA i\u015flemi IdP taraf\u0131nda ger\u00e7ekle\u015fir ve IdP, kullan\u0131c\u0131n\u0131n kimli\u011fini MFA ile do\u011frulad\u0131ktan sonra SAML onay\u0131 veya ID Token'\u0131 olu\u015fturur. Bu, uygulamalar\u0131n kendi MFA mekanizmalar\u0131n\u0131 geli\u015ftirmesine gerek kalmadan g\u00fc\u00e7l\u00fc g\u00fcvenlik sa\u011flamas\u0131na olanak tan\u0131r.<\/p>\n SAML entegrasyonlar\u0131nda IdP ve SP'nin birbiri hakk\u0131nda bilgi sahibi olmas\u0131 gerekir. Bu bilgiler, \"metadata\" ad\u0131 verilen bir XML dosyas\u0131nda tutulur ve IdP'nin ve SP'nin u\u00e7 noktalar\u0131n\u0131, genel anahtarlar\u0131n\u0131, destekledi\u011fi ba\u011flamalar\u0131 vb. i\u00e7erir. Bu metadata dosyas\u0131n\u0131n do\u011fru bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131, de\u011fi\u015f toku\u015f edilmesi ve g\u00fcncel tutulmas\u0131, SAML entegrasyonlar\u0131n\u0131n sorunsuz \u00e7al\u0131\u015fmas\u0131 i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Bu ileri d\u00fczey konulara hakim olmak, uygulaman\u0131z\u0131n sadece \u00e7al\u0131\u015fmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda g\u00fcvenli, \u00f6l\u00e7eklenebilir ve y\u00f6netilebilir olmas\u0131n\u0131 da sa\u011flayacakt\u0131r. Geli\u015ftirme s\u00fcrecinde bu en iyi uygulamalar\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmak, uzun vadede size b\u00fcy\u00fck faydalar sa\u011flayacakt\u0131r.<\/p>\n Bu kapsaml\u0131 makale boyunca, modern uygulamalar\u0131n vazge\u00e7ilmezi olan kimlik do\u011frulama protokolleri SAML ve OIDC'yi detayl\u0131 bir \u015fekilde inceledik. SAML'\u0131n kurumsal d\u00fcnyadaki sa\u011flam yerini, XML tabanl\u0131 yap\u0131s\u0131n\u0131, g\u00fcvenilirli\u011fini ve b\u00fcy\u00fck \u00f6l\u00e7ekli entegrasyonlardaki g\u00fcc\u00fcn\u00fc g\u00f6rd\u00fck. Di\u011fer yandan, OIDC'nin JSON\/JWT tabanl\u0131 hafif yap\u0131s\u0131n\u0131, modern web, mobil ve API uygulamalar\u0131yla olan m\u00fckemmel uyumunu ve geli\u015ftirici dostu \u00f6zelliklerini ke\u015ffettik. Her iki protokol\u00fcn de kendi avantajlar\u0131 ve dezavantajlar\u0131 oldu\u011funu, dolay\u0131s\u0131yla \"en iyi\" se\u00e7ene\u011fin olmad\u0131\u011f\u0131n\u0131, sadece uygulaman\u0131z\u0131n \u00f6zel ihtiya\u00e7lar\u0131na \"en uygun\" se\u00e7ene\u011fin bulundu\u011funu vurgulad\u0131k.<\/p>\n \u00d6zetle, uygulaman\u0131z\u0131n t\u00fcr\u00fc, hedef kitlesi, mevcut altyap\u0131n\u0131z ve geli\u015ftirici ekibinizin yetkinlikleri gibi fakt\u00f6rleri dikkatlice de\u011ferlendirmek, do\u011fru karar\u0131 vermenin anahtar\u0131d\u0131r. Kurumsal ve geleneksel entegrasyonlar i\u00e7in SAML hala g\u00fc\u00e7l\u00fc bir adayken, \u00e7evik, bulut tabanl\u0131 ve t\u00fcketici odakl\u0131 uygulamalar i\u00e7in OIDC tart\u0131\u015fmas\u0131z bir \u015fekilde \u00f6ne \u00e7\u0131kmaktad\u0131r. Hatta, bir\u00e7ok kurulu\u015fun hibrit bir yakla\u015f\u0131m benimseyerek her iki protokol\u00fcn de g\u00fc\u00e7l\u00fc y\u00f6nlerinden faydaland\u0131\u011f\u0131n\u0131 g\u00f6rd\u00fck.<\/p>\n Kimlik do\u011frulama teknolojileri s\u00fcrekli geli\u015fiyor. FIDO2 ve Passkeys gibi daha yeni, \u015fifresiz kimlik do\u011frulama standartlar\u0131 gelecekte daha fazla yer edinecek olsa da, SAML ve OIDC hala dijital kimlik y\u00f6netiminin temel direkleri olmaya devam edecektir. Gelece\u011fe bakarken, bu protokollerin nas\u0131l entegre edilece\u011fini ve yeni teknolojilerle nas\u0131l bir arada var olaca\u011f\u0131n\u0131 anlamak, geli\u015ftiriciler ve mimarlar i\u00e7in kritik \u00f6neme sahiptir. Unutmay\u0131n, do\u011fru kimlik do\u011frulama protokol\u00fcn\u00fc se\u00e7mek, uygulaman\u0131z\u0131n g\u00fcvenli\u011fini, kullan\u0131c\u0131 deneyimini ve \u00f6l\u00e7eklenebilirli\u011fini do\u011frudan etkileyen stratejik bir karard\u0131r.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Modern uygulamalarda kullan\u0131c\u0131 kimlik do\u011frulama s\u00fcre\u00e7leri karma\u015f\u0131kla\u015f\u0131yor mu? SAML ve OIDC aras\u0131ndaki temel farklar\u0131, avantajlar\u0131n\u0131, dezavantajlar\u0131n\u0131 ve uygulaman\u0131za…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-35683","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n\n
\n
\n\nOIDC Nedir ve Modern Uygulama Geli\u015ftirmedeki Rol\u00fc Nedir?<\/h2>\n
\n
\n
\n
\n\n\n{\n \"iss\": \"https:\/\/accounts.google.com\",\n \"azp\": \"your-client-id.apps.googleusercontent.com\",\n \"aud\": \"your-client-id.apps.googleusercontent.com\",\n \"sub\": \"101234567890123456789\",\n \"email\": \"user@example.com\",\n \"email_verified\": true,\n \"at_hash\": \"some_hash_value\",\n \"name\": \"John Doe\",\n \"picture\": \"https:\/\/lh3.googleusercontent.com\/a\/some_picture_id\",\n \"given_name\": \"John\",\n \"family_name\": \"Doe\",\n \"locale\": \"en\",\n \"iat\": 1678886400,\n \"exp\": 1678890000\n}\n<\/code><\/pre>\nSAML ve OIDC Aras\u0131ndaki Temel Farklar Nelerdir?<\/h3>\n
\n\n
\n \n\u00d6zellik<\/th>\n SAML (Security Assertion Markup Language)<\/th>\n OIDC (OpenID Connect)<\/th>\n<\/tr>\n<\/thead>\n \n Temel Protokol<\/strong><\/td>\n Ba\u011f\u0131ms\u0131z bir XML tabanl\u0131 protokold\u00fcr.<\/td>\n OAuth 2.0 yetkilendirme \u00e7er\u00e7evesinin \u00fczerine in\u015fa edilmi\u015f bir kimlik do\u011frulama katman\u0131d\u0131r.<\/td>\n<\/tr>\n \n Veri Format\u0131<\/strong><\/td>\n XML tabanl\u0131 (SAML Assertions). Daha detayl\u0131 ve yap\u0131land\u0131r\u0131lm\u0131\u015f.<\/td>\n JSON tabanl\u0131 (ID Token bir JWT'dir). Daha hafif ve modern web i\u00e7in optimize edilmi\u015ftir.<\/td>\n<\/tr>\n \n Odak Noktas\u0131<\/strong><\/td>\n Kimlik do\u011frulama ve yetkilendirme bilgisi de\u011fi\u015fimi (Federated Identity).<\/td>\n Kimlik do\u011frulama ve kullan\u0131c\u0131 kimlik bilgilerini g\u00fcvenli bir \u015fekilde elde etme. OAuth 2.0 ile yetkilendirme sa\u011flar.<\/td>\n<\/tr>\n \n Tipik Kullan\u0131m Alanlar\u0131<\/strong><\/td>\n Kurumsal uygulamalar, \u015firket i\u00e7i a\u011flar, devlet kurumlar\u0131, SaaS entegrasyonlar\u0131.<\/td>\n Modern web uygulamalar\u0131 (SPA), mobil uygulamalar, RESTful API'ler, t\u00fcketiciye y\u00f6nelik hizmetler.<\/td>\n<\/tr>\n \n Karma\u015f\u0131kl\u0131k<\/strong><\/td>\n Genellikle daha karma\u015f\u0131k bir \u00f6\u011frenme e\u011frisine ve uygulamaya sahiptir.<\/td>\n Daha basit ve geli\u015ftirici dostu; \u00f6zellikle OAuth 2.0'a a\u015fina olanlar i\u00e7in kolay.<\/td>\n<\/tr>\n \n Geli\u015ftirme Ortam\u0131<\/strong><\/td>\n Taray\u0131c\u0131 tabanl\u0131 ak\u0131\u015flar i\u00e7in daha uygundur.<\/td>\n Taray\u0131c\u0131, mobil ve API bazl\u0131 ak\u0131\u015flar i\u00e7in m\u00fckemmeldir.<\/td>\n<\/tr>\n \n Token Tipi<\/strong><\/td>\n SAML Assertion (XML belgesi).<\/td>\n ID Token (JWT) ve Access Token.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Uygulaman\u0131z \u0130\u00e7in Do\u011fru Protokol\u00fc Nas\u0131l Se\u00e7melisiniz?<\/h2>\n
\n
\n
\n
\n
\n
\n
\u0130leri D\u00fczey Konular ve En \u0130yi Uygulamalar<\/h2>\n
JWT G\u00fcvenli\u011fi ve Refresh Token Kullan\u0131m\u0131<\/h3>\n
\n
Protokollerin Geni\u015fletilebilirli\u011fi<\/h3>\n
\n
API Gateway ile Entegrasyon<\/h3>\n
Multi-Factor Authentication (MFA) Entegrasyonu<\/h3>\n
SAML Metadata Y\u00f6netimi<\/h3>\n
Sonu\u00e7: Gelece\u011fin Kimlik Do\u011frulamas\u0131<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n