1 puan yazan GN⁺ 2024-11-11 | 1 yorum | WhatsApp'ta paylaş
  • OpenID Connect ile ilgili 9 spesifikasyon ISO/IEC standardı olarak yayımlandı; Core 1.0, Discovery, Dynamic Client Registration, logout spesifikasyonları ve OAuth 2.0 response mode’ları da uluslararası standartlar sistemine girdi
  • OpenID Foundation, bunları Aralık 2023’te PAS (Publicly Available Specifications) yöntemiyle ISO’ya sundu; ardından ISO onay oylamasından geçerek yayımlanma süreci tamamlandı
  • ISO standardizasyonu sayesinde, uluslararası anlaşmalarla tanınan standart kuruluşlarının spesifikasyonlarını zorunlu tutan yargı bölgelerinde de OpenID Connect dağıtımı kolaylaşabilir
  • Sunumdan önce OpenID Connect working group, bilinen düzeltmelerin ISO sürümüne dahil edilmesi için errata corrections uygulama sürecini yürüttü
  • OpenID Foundation, bu PAS sürecinden edindiği deneyime dayanarak FAPI 1.0’ı ve nihai hale geldikten sonra eKYC-IDA ile FAPI 2.0 spesifikasyon ailelerini de ISO yayımı için sunmayı planlıyor

ISO/IEC standardı olarak yayımlanan spesifikasyonlar

PAS sunumu ve ISO onayı

  • OpenID Foundation adına OpenID Connect spesifikasyonlarının sunumu Aralık 2023’te PAS (Publicly Available Specifications) biçiminde yapıldı
  • ISO onay oylamasının ardından söz konusu spesifikasyonlar ISO/IEC standardı olarak yayımlandı
  • ISO, uluslararası anlaşmalarla tanınan standart kuruluşlarından biri olduğundan, bu tür kuruluşların standartlarının kullanılmasını yasal olarak zorunlu kılan yargı bölgelerinde OpenID Connect’in benimsenme alanı genişleyebilir

ISO sürümüne dahil edilen düzeltmeler

  • Sunumdan önce OpenID Connect working group, spesifikasyonlara errata corrections uygulama sürecini yürüttü
  • Bunun sonucunda ISO sürümüne bilinen düzeltmeler yansıtıldı

Sonraki ISO sunum planı

  • OpenID Foundation, ISO PAS sunum sürecini bir kez tamamladıktan sonra ek nihai spesifikasyon ailelerini de ISO yayımı için sunmayı planlıyor
  • Sıradaki hedefler arasında FAPI 1.0 spesifikasyonu yer alıyor
  • eKYC-IDA ve FAPI 2.0 spesifikasyonları ise nihai hale geldikten sonra sunulacak hedefler olarak belirlenmiş durumda

1 yorum

 
GN⁺ 2024-11-11
Hacker News yorumları
  • Yaklaşık 17 yıl önce OpenID ile epey yakından ilgilenmiş olmama rağmen (https://simonwillison.net/search/?tag=openid&year=2007), OpenID Connect’in “tanımlayıcı bir URL’dir ve o URL’nin sahipliğini kanıtlar” şeklindeki özgün OpenID fikriyle neredeyse alakasız olduğunu anlamam utandırıcı derecede uzun sürdü.
    OpenID Connect aslında OAuth’un evrimleşmiş hâline daha yakın.

    • Gelecekteki kendime not olarak yazarsam: OpenID Connect (OIDC) ağırlıklı olarak kimlik doğrulama ile ilgilenir; OAuth, daha doğrusu OAuth v2.0 ise yetkilendirme ile ilgilenir.
      OpenID Connect’i OAuth’un evriminden ziyade, vizyon ve ruh açısından OpenID’nin evrimi olarak görüyorum. OIDC, OpenID gibi kullanıcı kimliği ve kimlik doğrulamaya odaklanır; ancak OpenID’den farklı olarak tamamen yeni bir kimlik doğrulama akışını baştan icat etmedi, zaten kimlik doğrulama amacıyla yanlış kullanılan OAuth spesifikasyonunun üzerine bir kimlik doğrulama akışı koyarak ana hedefine ulaştı.
    • OAuth2 bileşenlerin bir araya getirilmesi konusunda çok esnek; OIDC ise bu “nasıl birleştirilmeli” konusunda pek çok iyi pratik sunuyor.
      Bu yüzden OIDC uyumluluğu hedeflenmeyen sistemler bile çoğu zaman kısmen OIDC’yi izliyor. OIDC standardının bir kısmı zaten ihtiyaç duyulan şeyi sağlıyorsa tekerleği yeniden icat etmeye gerek yok.
    • İsimlendirme tam bir kâbus.
      OpenID Connect, OAuth2’ye (RFC 6749) kimlik doğrulama katmanı ekleyen bir uzantı; OAuth2 ise izin vermeye yönelik bir yetkilendirme çerçevesi.
      Buna karşılık OAuth 1.0/1.0a ile OpenID 1/2 sadece adları benzer olan, birbiriyle ilgisiz ve uyumsuz protokoller; 2024 itibarıyla çoğunlukla alakasızlar. Arama yaparken dikkat etmek gerek.
    • Ben OpenID Connect’i OAuth2 üzerine inşa edilmiş bir özelleştirme olarak anlıyorum.
    • 2008’de Webstock’ta yapılan bir sunum sayesinde OpenID’ye ilk kez ilgi duymuştum.
  • Bu hiçbir açıdan iyi bir şey değil. Öncelikle, görmek için para ödemeniz gereken ücretli standartlar gerçekten kötü.
    İkincisi, ihtiyaç duyulduğunda sonsuz bir zaman israfına dönüşmeyen standartlar ve uygulamalar tasarlamak için daha fazla çaba harcanmasını isterdim.

    • ISO konusunda katılıyorum ama bu örnekte anlamlı bir geçiş ücreti bariyeri olduğunu söylemek zor. Standardın kendisi zaten ücretsiz yayımlanmış durumda; bu olan da ISO’nun standartlaştırma ad alanında bir tanımlayıcı tahsis etmeye benziyor.
      Yine de ISO standart numarası almanın internete bir HTML belgesi koymaya göre ne avantajı olduğundan emin değilim.
    • İnternet tarafında, neden böyle şeylerin RFC yapılmadığını merak ediyorum. E-posta ve TCP de RFC, diğer temel unsurlar da öyle; küresel şirketler de bunları sürekli kullanıyor.
  • Standartlar iyi ama ISO gibi büyük standardizasyon kuruluşlarının standartları görmek için para istemesi sinir bozucu.
    Muhtemelen bazı şirketler veya sektörler, IETF’in ya da kirli açık kaynak hippi topluluklarının yaptıklarından ziyade bu tür kuruluşların “gerçek” standartlarını talep ettiği içindir.

    • Onların iddiasına göre bu, daha az gelişmiş bölgelere erişilebilirlik ve finansman sağlamak içinmiş.
    • Standart” ile “paralı” kavramları birbiriyle çelişiyor gibi geliyor. Bir yöntemin standart, yani en yaygın yöntem olmasını istiyorsanız, yaygın biçimde uygulanabilmesi için yeterince erişilebilir olması gerekir.
    • Çoğu standart düşük fiyatlıdır ve zararına satılıyor sayılır. Bunun yerine ISO’ya veya IEEE’ye bağış yapmak isterseniz, standart yazma maliyetini düşürmeye yardımcı olur.
    • Hükümet veya ülke bağlamında, ISO pek çok uluslararası anlaşmada tanındığı için OpenID Foundation standardı yerine ISO standardı kullanımına onay almak çoğu zaman daha kolay diye anlıyorum.
      Bu yüzden OpenID Connect’in bir ISO numarasıyla yayımlanması, bazı projelerde benimsenmesini kolaylaştırır. Elbette OpenID Connect’in kendisi ücretsiz olarak okunup kullanılmaya devam edecek; ancak yukarıdaki durumda olan insanlar için daha kolay bir seçenek doğmuş oluyor.
  • ISO özgür olmayan bir çöp ve yazılım ekosistemine faydası yok.
    ISO 8601’e bakınca aşırı karmaşık; bakımcılar ücretsiz taslakları kullandığı için çoğu zaman doğru uygulanmıyor ve aslında bir şeyi doğru düzgün çözmüyor. Örneğin duvar saati zamanını ifade edemediği için, saat diliminin değişebileceği gelecekteki tarihlerde sorun çıkarıyor.
    Eskiden mp4 ile de uğraşmıştım; Apple yığınında değişiklikler olduğu için ISO’nun tek başına yeterli olmadığını görmüştüm.

    • Belirli şikâyeti anlıyorum ama duvar saati zamanını ifade etmemesini daha çok bir özellik olarak görüyorum.
      Eleştiri genellikle yaz saati değişikliği gibi varsayımlara kayıyor. “4 yıl sonra Absurdistan yerel saatiyle 14:00’ü, UTC ile ilişkisi ne olursa olsun belirtmek istiyorum ama yapamıyorum” türü eleştiriler yaygın. Ancak varsayımı biraz daha ileri götürürseniz Absurdistan denizaşırı bir bölge ekleyebilir, bir ittifaka katılabilir ya da saat dilimini ve yaz saati uygulamasını değiştirebilir.
      Sorunu düşününce, yerel saat tanımının kendisi değişebileceğinden, olası tüm değişiklikleri eksiksiz tanımlamadıkça gelecekteki yerel saati belirtmek imkânsızdır. Sonuçta ya gelecekteki atom saati tik sayısını (TAI) belirleyip kullanım anında yerel saate yorumlamak ya da sabit bir zamanı belirtip kullanım anında yerel saat olarak yorumlamak gerekir.
    • ISO 8601’in bir alternatifi olup olmadığını merak ediyorum. Benim tek şikâyetim bazı şeyleri ifade etmenin birden fazla yolu var gibi görünmesiydi; duvar saati zamanı sorununu bilmiyordum.
      Yeni JS Temporal API’sinin bunu ele alıp almadığını da merak ediyorum. Epey derine inmiş gibi görünüyordu.
  • ISO gibi okumak için ücretli standartlar insanlığın ilerlemesini aktif olarak engelliyor. Bu tür davranışların teşvik edilmemesini isterim.

    • C++ için güncel standart taslakları ücretsiz olarak yayımlanıyor https://en.cppreference.com/w/cpp/links#C.2B.2B_standard_doc...
      Son taslak ile resmî standardın pratikteki içerik açısından neredeyse aynı olduğunu anlıyorum. OIDC standart taslağı da muhtemelen bir yerlerde yayımlanmıştır.
    • Her şeyin siyah beyaz olması gerekmiyor. Gri alanlar olduğunu kabul etmekte sorun yok.
      O mühendislerin insanlığın ilerlemesini üretirken aynı zamanda insanlığın ilerlemesine aktif olarak zarar verdiğini söylemek tuhaf.
  • Kimlik sağlama, icat edilmemesi gereken bir canavar
    2000'lerin ortasında kendi OpenID sunucumu işletecek kadar hayranıydım, ama bu kavramın tamamının temelde ne kadar kusurlu olduğunu bilmiyordum
    Kimlik, kişiye içkin, devredilemez bir niteliktir; başka bireylerin, şirketlerin/web sitelerinin, hükümetlerin vb. “sağlayabileceği” bir şey değildir. Onlar ancak pasaport vermek gibi kimlik bilgileri sağlayarak bunu kanıtlayabilir
    En azından WebAuthn bu kısmı doğru ele aldı

    • Sağlanan kimliğin tam olarak sen ve yalnızca sen olduğun varsayımına dayanmıyor mu? Ben bu kimlikleri bir kimlik sağlayıcının üzerindeki takma adlar olarak gördüm ve öyle kullandım
      Bazı kimlikler yeterince çok yerde kullanıldığı için bazı taraflar açısından bunun bana ait olduğunu inkâr etmek zor olabilir; ama o durumda bile, o kimliği gören taraflar içinde benim olduğumu kanıtlayabilecek olanlar küçük bir alt kümedir
    • Kanıtlama ile sağlama arasındaki ayrımın pratik bir sonucu var mı, yoksa tamamen felsefi bir ayrım mı merak ediyorum
  • Google, MS, Apple dışında hesap oluşturulabilen bağımsız OIDC issuer'ları hâlâ kaldı mı?
    Kısa süre önce GitHub hesabı kullanmadan Tailscale hesabı oluşturmak istedim ama yapamadım
    Eskiden openid.net ve Ubuntu One'ın böyle bir hizmet sunduğunu sanıyorum, ama bildiğim kadarıyla durduruldu

    • Hâlâ birkaç tane var; https://gitlab.com benim sık kullandıklarımdan biri
      Ancak böyle hizmetler için gereken güvenlik ve destek maliyetleri yüksek; özellikle ücretsiz sunmak küçük kuruluşlar için pek gerçekçi değil. Bunu mümkün kılan ölçek ekonomileri büyük ve büyük şirketler kurumsal ürünlere para ödediğinde özellikle iyi işliyor
  • OpenID Connect oldukça basit bir protokol. Spesifikasyonu (https://openid.net/specs/openid-connect-core-1_0.html) okuyup yaklaşık bir günde büyük kısmını anlayabildim
    Spesifikasyonu okumak istemeyenler için, basit HTTP istekleriyle OpenID istemcisi uygulamaya yönelik kapsamlı bir öğretici de yazdım (https://spapas.github.io/2023/11/29/openid-connect-tutorial/)
    Örnekler Python kullanıyor ama istediğiniz dilde uygulamak zor olmayacaktır. Karmaşık kısımların çoğu JWT token'larını çözümleyip denetlemekte
    Bu elle yazılmış istemciyi yaklaşık 1 yıldır gerçek bir production projede Keycloak kimlik doğrulaması için kullanıyorum ve her şey kusursuz çalışıyor
    Not: Sitemde çok fazla reklam olduğunu biliyorum. Ne yazık ki Google Ads'i düzgün ayarlayacak vaktim olmadı ve daha iyi bir alternatif de bulamadım. Okurken reklam engelleyici kullanabilirsiniz

    • Yazı çok ilginç ve iyi yazılmış
      Yine de basit gibi öznel ifadeler konusunda dikkatli olmak iyi olur. Okur zorlandığını hissederken yazar basit derse, bu epey yıldırıcı olabilir
    • Harika bir öğretici
      Yine de OIDC'nin kolay olduğu konusunda hâlâ ikna olmuş değilim. Keycloak muazzam bir karmaşıklığı gizliyor ve geliştiriciler bunu can sıkıntısından böyle yapmış değiller. Örneğin SSO zaman aşımı, istemci zaman aşımı, çeşitli token zaman aşımları gibi çok sayıda farklı zaman aşımı ayarı var
  • ISO standartları etrafındaki gelir modeli ve kurumsal işleyiş genel olarak çok şüpheli geliyor
    Daha az bilinen bir ipucu olarak, dostane Estonya sitesi https://evs.ee üzerinde standartların daha ucuz sürümlerini arayabilirsiniz. Genellikle orijinalle neredeyse aynı içeriğe sahip kendi sürümlerini oluşturuyorlar. Ne yazık ki bu durumda gerçek standardı benzer bir fiyata sunuyor gibi görünüyorlar https://www.evs.ee/en/search?OnlySuggestedProducts=false&que...
    Daha sonra daha iyi fiyatlı kendi sürümleri çıkar mı diye siteyi takip etmeye değer. Genellikle fiyatı orijinalin yaklaşık %10'u düzeyinde oluyor. Estonya'nın güzel işler yaptığına dair bir veri noktası daha
    Tıbbi cihaz mevzuat uyumluluğu alanında çalıştığım için epey şüpheli standartlaştırma kuruluşlarıyla sık sık muhatap oluyorum https://openregulatory.com/accessing-standards/
    “Standartlaştırma para gerektirir”, “bu kuruluşlar iyi işler yapıyor” gibi yaygın argümanların hepsini duydum ama hiç katılmıyorum. Bir şey standartsa, yasa gibi bir şeye dönüşür diye düşünüyorum. İnsanlar ona uyabilmeli; bunun için de serbestçe erişilebilir olmalı. AB hukuk sözcüsü de aynı fikirde gibi görünüyor https://openregulatory.com/maybe-eu-standards-are-becoming-f...
    PDF'leri şüpheli şekilde para karşılığı satmayı gerektirmeyen pek çok standartlaştırma var. Aklıma ECMAScript ve ANSI C geliyor; daha niceleri de var

  • ISO yayını hâline getirmek, satın alma departmanları açısından sorumluluktan kaçınma kalkanı olur
    Ne de olsa ISO standartları paketine uyum istedim diye kimse işten atılmadı