Geliştirici İlişkileri Mühendisi
Sektör, şifrelerden ve fiziksel cüzdanlardan uzaklaşırken modern bir kullanıcı yolculuğu sunmak için hem sorunsuz kimlik doğrulama hem de güvenilir kimlik doğrulama gerekir. Geçiş anahtarları tek dokunuşla güvenli giriş imkanı sunsa da cihaz değiştirme, kullanıcı etkileşiminde en büyük düşüş noktalarından biri olmaya devam ediyor. Yeni Google Play Zero Tap Sign In standardını karşılamak için Restore Credentials API'yi kullanarak taşıma zorluklarını nasıl azaltacağınızı öğrenin.
Bu oturumda, Android Kimlik Bilgisi Yöneticisi ile tek bir entegrasyonun geçiş anahtarlarını, sessiz cihaz geri yüklemeyi ve dijital kimlik bilgilerini nasıl birleştirdiğini inceleyeceğiz. Bu sayede, kimlik özelliklerini doğrudan cihazdan doğrulayabilir ve zahmetsiz, güvenli bir ilk katılım akışı oluşturabilirsiniz.
Transkript
Herkese merhaba.
Bugün bize katıldığınız için çok teşekkür ederiz.
Bugün, kimlik doğrulamanın ve dijital kimliğin geleceği hakkında konuşmaktan heyecan duyuyoruz.
Ben Tom Colvin.
Apptaura'da CTO ve Android'de GDE olarak çalışıyorum. Google'da Kıdemli Android Geliştirici İlişkileri Mühendisi olan Chiping Yeh de bana eşlik ediyor.
Eski şifre artık kullanılmıyor.
En azından öyle olması gerekir.
Bugün size şifresiz bir dünyadan bahsedeceğim.
Şifreler, güvenlik altyapımızda iyi bilinen bir güvenlik açığıdır.
Güvenli bir şekilde saklansalar bile kimlik avı, sunucu ihlalleri ve kimlik bilgisi doldurma gibi otomatik saldırılara karşı savunmasızdırlar.
Sektör olarak bu sorunu, karmaşıklığı zorunlu kılarak çözmeye çalıştık: özel karakterler, sayılar, zorunlu rotasyonlar.
Kanıtlar, bu yaklaşımın başarısız olduğunu gösteriyor. Bunun bir nedeni de, süreci ne kadar zorlaştırırsanız, paradoksal olarak güvensiz davranışları o kadar teşvik etmenizdir.
Çünkü düzenli olarak değiştirilen karmaşık bir şifrenin yapışkan not kağıdına yazılma olasılığı yüksektir.
SMS tabanlı iki faktörlü kimlik doğrulamanın bile SIM değiştirme gibi müdahalelere karşı savunmasız olduğu kanıtlanmıştır.
Ancak günümüzde bu sorun büyük ölçüde çözülmüştür.
Geçiş anahtarları, FIDO standartlarına göre oluşturulur ve ortak-özel anahtar kriptografisi kullanır.
Kimlik avına karşı son derece dirençlidirler, sunucu ihlallerinde açığa çıkmazlar ve doğrudan ekran kilidi aracılığıyla kullanıcının telefon güvenliğine bağlıdırlar. Ekran kilidi de çoğu durumda biyometrik verilerimize, parmak izlerimize vb. dayanır. Ayrıca, platformlar arasında birleşik bir deneyim sunarak ve karmaşık şifreleri hatırlama ihtiyacını ortadan kaldırarak kullanıcı deneyimini aktif olarak iyileştirirler.
Bugünkü manifestomuz basit.
Şifresiz bir dünyaya geçme zamanı geldi.
Bunu yapacak araçlar da elimizde mevcut.
Android'de bu geçişi yapmanın temelinde Jetpack Kimlik Bilgisi Yöneticisi yer alıyor.
Android 4.4'e kadar tüm sürümlerde desteklenir. Android 9'dan itibaren geçiş anahtarlarını destekler. Geçiş anahtarlarının yanı sıra Google ile oturum açma gibi birleşik oturum açma gibi geleneksel kimlik doğrulama yöntemlerini destekleyen tek ve birleşik bir API sağlar. Gerekirse şifreleri de sorunsuz bir şekilde kullanabiliriz.
Credential Manager API'yi çağırdığınızda, kullanıcının görmek istediği kimlik doğrulama yöntemini seçmek için kullanıcı arayüzünü işler.
Ardından, güvenli bir şekilde elde edilen doğru kimlik bilgisini döndürmek için zorlu işleri yapar.
Oturum açma, kaydolma ve kimlik bilgilerini yedekleme işlemlerini destekler.
Ayrıca, kimlik bilgilerini güncellemek ve silmek için de kullanabilirsiniz.
Ayrıca kullanıcıların şifrelerini ve geçiş anahtarlarını kimlik bilgisi sağlayıcılar arasında yalnızca birkaç tıklamayla ve dosya indirmeye gerek kalmadan taşımasına olanak tanır.
Kullanıcılara verileri üzerinde tam kontrol ve gerektiğinde sağlayıcı değiştirme özgürlüğü sunmak için tasarlanmıştır.
Kimlik Bilgisi Yöneticisi; saat, TV, XR, otomotiv, telefon, katlanabilir cihaz ve tablet gibi birçok form faktörünü destekler.
Bizim için en önemlisi de geçiş anahtarları için özel bir akışa sahip olması.
Kullanıcı, kaydolma sırasında bu ekranı görür.
Uygulamam, Kimlik Bilgisi Yöneticisi'ne geçiş anahtarı kimlik doğrulamasının kullanılabildiğini bildirir ve arka uçtan toplanan ayrıntıları sağlar.
Kayıt Ol'a dokunduğunuzda Kimlik Bilgisi Yöneticisi, ekran kilidi istemi içeren bir alt sayfa gösterir.
Bu genellikle parmak izi veya yüz taraması gibi biyometrik verilerle açılır.
Ardından Kimlik Bilgisi Yöneticisi, geçiş anahtarını oluşturma gibi karmaşık kriptografi işlemlerini gerçekleştirir.
Geçiş anahtarını kimlik bilgisi yöneticime kaydeder. Bu örnekte Google Şifre Yöneticisi'ni kullanıyorum ancak başka bir yönetici de olabilir.
Kod şu şekilde görünür:
val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
requestJson = registerRequestJson
)
val createCredentialResponse = credentialManager.createCredential (
context = localActivity,
request = createPublicKeyCredentialRequest
)İlk olarak, arka uç sağlayıcının ayrıntılarını kullanarak bu createPublicKeyCredentialRequest nesnesini oluşturuyoruz. Bu, registerRequestJson.
Ardından, credentialManager.createCredential sihirli yöntemini çağırırız.
Bu isteği ve Local Context'i iletiriz. Bu sayede kullanıcı arayüzü gösterilir.
Bu arada, burada herhangi bir kullanıcı arayüzü kodu yazmam gerekmediğini fark etmişsinizdir.
Kimlik Bilgisi Yöneticisi, bu işlemi bizim için tamamen halleder.
Oturum açma işlemi bu şekilde yapılır.
Kullanıcı için bu işlem, kaydolma sürecine çok benzer.
Tek bir kilit açma istemiyle işlemi tamamlayabilirsiniz.
Geliştiriciler içinse bu durum biraz farklıdır.
val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
requestJson = authenticationRequestJson
)
val signInRequest =
GetCredentialRequest(listOf(getPublicKeyCredentialOption))
val result = credentialManager.getCredential (
context = localActivity,
request = signInRequest
)İlk olarak, GetPublicKeyCredential örneği oluşturmak için arka uçtan oturum açma ayrıntılarını alırız.
Kimlik Bilgisi Yöneticisi'ne hangi tür kimlik bilgilerini desteklediğimizi bildiririz.
Burada yalnızca geçiş anahtarları gösterilir.
Ancak istersek başka türde kimlik bilgileri de ekleyebiliriz.
Ardından, az önce istediğimiz kimlik bilgileri listesini ileterek credentialManager.getCredential yöntemini çağırırız.
Yine kullanıcı arayüzü kodu yok.
Kullanıcı arayüzü kodu yazmanız gerekmez.
Kimlik Bilgisi Yöneticisi bu işlemi bizim için tamamen halleder.
Kullanıcıyı en sık kullanılan seçeneğe yönlendirir ve diğer seçenekleri yedek olarak bırakır.
Bu sayede, günümüzün en can sıkıcı kimlik doğrulama sorunlarından biri otomatik olarak çözülür.
Fark ettiniz mi?
Bu, oturum açmak için en son kullandığım yöntemi hatırlamaktır.
Bakın, yanıt alt sayfada düzgün bir şekilde sunuluyor.
Bu arada, bu durum kullanıcı için yalnızca can sıkıcı bir durum değildir.
Bu, gerçek bir sürtüşme noktasıdır.
Gereksiz hesap kurtarma işlemlerine neden olur ve terk edilen alışveriş sepetleri gibi ticari etkileri vardır.
Kimlik Bilgisi Yöneticisi'ni denemek için kullanabileceğiniz demo uygulama kodumu aşağıda bulabilirsiniz.
Bu akışları kendi cihazınızda görebilirsiniz.
Sol tarafta da resmi Google kod örnekleri var.
Bu, geçiş anahtarı oluşturma işlemini gerçekleştirir.
Mevcut şifre kullanıcılarını geçiş anahtarlarına yükseltme konusunda ne düşünüyorsunuz?
Bu konuda kullanabileceğiniz güçlü bir araç, koşullu oluşturmadır.
Kullanıcınız şifresini kullanarak yeni oturum açtıysa ve şifre, desteklenen bir kimlik bilgisi sağlayıcı tarafından otomatik olarak doldurulduysa kullanıcının etkin bir şekilde etkileşimde bulunduğunu ve kimliğini yeni doğruladığımızı biliriz.
Bu durumda, Koşullu Oluşturma özelliği arka planda otomatik olarak geçiş anahtarı oluşturulmasını istememize olanak tanır.
Kullanıcının iş akışını kesintiye uğratmaz.
Şifre... Geçiş anahtarı sessizce oluşturulur ve saklanır.
Google Şifre Yöneticisi, bu işlemin gerçekleştiğini onaylayan bir bildirim gösterir.
Diğer şifre yöneticileri farklı şekilde çalışabilir.
Koşullu oluşturma kodu, kaydolma koduna çok benzer.
val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
requestJson = registerRequestJson,
preferImmediatelyAvailableCredentials = false,
isConditional = true
)
val createCredentialResponse = credentialManager.createCredential (
context = localActivity,
request = createPublicKeyCredentialRequest
)Sihirli işaret isConditional true olarak ayarlandığından kullanıcı bu kullanıcı arayüzünü görmez.
Fırsatçı bir şekilde çalıştığı için bunu bir try-catch içine koyacağız.
Hataları sessizce ele alacağız. Böylece, işlem başarısız olursa kullanıcıyı rahatsız etmeyiz.
Ardından geçiş anahtarı, kullanıcının Kimlik Bilgisi Yöneticisi'ne kaydedilir ve bir sonraki seferde kullanılabilir.
Kimlik Bilgisi Yöneticisi, kimlik bilgisi sağlayıcıların kimlik bilgilerini güvenli bir şekilde içe ve dışa aktarmasına da olanak tanır.
Sadece birkaç tıklamayla.
İndirme gerekmez.
Bu sayede, bilgilerin güvenliğini sağlarken daha fazla esneklik elde edersiniz.
Akış şu şekildedir.
Kullanıcı, yeni kimlik bilgisi sağlayıcısında kimlik bilgilerini içe aktarmayı ister.
Ardından, Kimlik Bilgisi Yöneticisi içe aktarma kullanıcı arayüzünü işleyerek kullanıcının kimlik bilgisi verilerinin kaynağını seçmesine olanak tanır.
Dışa aktarma işlemini yapan kimlik bilgisi sağlayıcı, kendi kullanıcı arayüzünü sunabilir. Bu sayede kullanıcıyı bilgilendirebilir ve ilgili uyarıları gösterebilir.
Son olarak, kullanıcının yeni kimlik bilgisi sağlayıcısına güvenli bir kanal üzerinden veriler iletilir.
Bu sayede, kullanıcı etkileşimi olmadan içe aktarabilir.
Peki kullanıcı, uygulamasından veya web sitesinden bir geçiş anahtarını iptal ederse ne olur?
Bu durumda, kimlik bilgisi sağlayıcı bu durumdan haberdar olmayabilir.
Kullanıcı bir sonraki oturum açma denemesinde, Kimlik Bilgisi Yöneticisi bu geçersiz geçiş anahtarını sunar ve kullanıcının denemesi reddedilir.
Benzer şekilde, bir kullanıcı, kullanıcı adını veya görünen adını güncellediğinde senkronizasyon gerekir.
Artık Signal API ile uygulamanız bu belirli durumları kimlik bilgisi sağlayıcıya bildirebilir.
Örneğin, iptal edilen bir şifreyle oturum açma durumunu ele alalım.
Uygulamanız bu belirli hata durumunu yakalayabilir ve kullanıcının kimlik bilgisi sağlayıcısına bildirmek için kullanabilir.
Kimlik bilgisi sağlayıcı, söz konusu geçiş anahtarının sunulmaması için kendini güncelleyebilir.
Bunlar, Kimlik Bilgisi Yöneticisi'nin özelliklerinden bazıları. Kullanıcıların geçiş anahtarlarını kullanarak kaydolmasını sağlamak ve oturum açarken geçiş anahtarlarını diğer yöntemlere göre önceliklendirmek için son derece faydalı.
Ancak asıl amacımızın tamamen şifresiz bir dünyaya geçmek olduğunu unutmayın.
Kimlik Bilgisi Yöneticisi bu hedefe nasıl yardımcı olur?
Önerdiğimiz beş adımlı süreç şu şekildedir.
İlk iki adımda, şifre kullanan kullanıcılarınızı geçiş anahtarlarına geçirirsiniz.
İlk olarak, koşullu oluşturma özelliğini kullanarak fırsatçı bir şekilde deneriz.
Böyle bir fırsat ortaya çıkmazsa kullanıcının müdahalesine ihtiyaç duyarız. Bu durumda, kullanıcılardan geçiş anahtarı oluşturmalarını isteyen uygulama içi davetler göndeririz.
Bu bilgileri kademeli olarak daha belirgin bir şekilde göstermeye başlayabiliriz.
Kullanıcı açısından bakıldığında, genellikle yalnızca biyometri gibi ekran kilidi bilgilerini sağlamaları yeterlidir.
Analizler, kullanıcılarınızın büyük çoğunluğunun geçiş anahtarı kullanan hesapları olduğunu gösterdiğinde geçiş anahtarları tüm yeni kullanıcılar için zorunlu hale getirilebilir.
Ancak bu son üç adımda eski kullanıcılarla ilgileniyoruz.
Geçiş anahtarı kullanıcılarının şifrelerini kaldırmalarını öneririz.
Bu nedenle 3. adımda, hesap ayarlarında çok net bir Şifreyi Sil seçeneği sunarak bu işlemi manuel olarak yapmalarına izin veriyoruz.
4. adımda, şifre silme işlemini teşvik etmeye başlarız. Örneğin, uygulama içi bildirimler ve eğitici metinler kullanırız.
Son olarak, şifre silme işlemini etkinleştirme yerine kapsamı dışında kalmayı seçmek olarak değiştirirsiniz.
Sonunda, bu son kapsam dışında kalma seçeneği de ortadan kalkabilir.
Analizler, şifre akışlarını uygulamadan tamamen kaldırma konusunda bize güven verecek.
Dolayısıyla, şifresiz bir dünyaya geçiş artık gelecekte bir zamanda gerçekleşecek teorik bir güvenlik kavramı değil.
Bu özellik büyük ölçüde desteklenir.
API'ler sağlam, kullanıcı deneyimi mükemmel.
Geçiş anahtarı akışlarını Kimlik Bilgisi Yöneticisi ile entegre etmeye hemen başlamanızı öneririz.
Kullanıcılarınızı geçiş yapmaya teşvik edin ve şifreleri artık geçmişte bırakalım.
Teşekkür ederiz.
Şimdi sözü, cihaz taşıma ve kimlik alanındaki bir sonraki gelişmeden bahsetmesi için Chiping'e bırakıyorum.
Mükemmel.
Teşekkürler, Tom.
Tom'un da belirttiği gibi, kullanıcı cihazlarında sorunsuz kimlik doğrulama çok önemlidir.
Peki kullanıcı yeni bir telefon aldığında ne olur?
Günümüzde kullanıcı yolculuğundaki en büyük düşüş genellikle kullanıcılar cihaz değiştirdiğinde gerçekleşir.
Bugün öncelikle bu sorunu nasıl çözdüğümüzden bahsedecek, ardından kimlik bilgisi geri yüklemeyle ilgili olarak yakında Google Play Store'da zorunlu hale gelecek bir şartı kısaca ele alacağım.
Nisan 2027'den itibaren Google Play, uygulamaların tam yayınlama özelliklerini ve Google Play Store'da optimum görünürlüğü korumak için tek dokunuşla oturum açma şartlarını karşılamasını zorunlu kılacak.
Hiç dokunmadan oturum açma nedir?
Bu sayede kullanıcılar yeni bir cihaza geçiş yaparken uygulamanızda manuel olarak yeniden kimlik doğrulaması yapmak zorunda kalmaz.
Bunu nasıl uygulayabiliriz?
Bunun için önerdiğimiz birincil yöntem, Kimlik Bilgisi Yöneticisi aracılığıyla Android'in Restore Credentials API'sini kullanmaktır.
Bu API, kullanıcının cihazına veya kullanıcının yedekleme ayarlarına göre buluta kaydedilen bir geri yükleme anahtarı oluşturmanıza olanak tanır.
Bu anahtarı, kullanıcı oturum açtıktan sonra arka planda oluşturmanızı öneririz.
Bu diyagramda, uygulamada oturum açan bir kullanıcı gösterilmektedir.
Ardından, kullanıcı uygulamayı kullanırken geri yükleme anahtarı oluşturulur.
Bu anahtar daha sonra yerel olarak veya etkinleştirilmişse uzaktan bulutta depolanır.
Kullanıcı yeni cihazını kurarken geri yükleme kimlik bilgisi, cihaz kurulum işlemi sırasında arka planda sessizce aktarılır.
Kullanıcılar, verileri buluttan veya cihazlar arası aktarımdan geri yüklemeyi seçebilir.
Ardından, uygulamanız açıldığında Credential Manager API'yi çağırarak bu geri yükleme anahtarını kullanabilir ve kullanıcının yeni cihazda ilk başlatma sırasında oturum açmasını sağlayabilirsiniz.
Bu sayede kullanıcı, uygulamanıza hemen hızlı ve güvenli bir şekilde giriş yapabilir.
Uygulamanızın kurulumdan hemen sonra açılmadan geri yüklenmesini istiyorsanız bunu yapmak için özel bir yedekleme aracısı uygulayabilirsiniz.
Bu sayede kullanıcı, uygulamanızı manuel olarak açmadan uygulamanıza giriş yapabilir.
İş ortaklarımızdan bazıları bu özelliği uygulamalarında kullanmaya başladı.
Uber, dünyanın en büyük araç paylaşımı şirketidir. Milyonlarca kişiye ulaşım hizmeti sunmanın yanı sıra yemek teslimatı, sağlık hizmetleri için ulaşım ve yük lojistiği de sağlar.
Erişim kolaylığı çok önemlidir.
Kullanıcılar yeni bir cihaza geçtiklerinde Uber uygulamasında tekrar oturum açmak veya her seferinde SMS tabanlı tek seferlik kimlik doğrulama yapmak zorunda kalmadan sorunsuz bir geçiş bekler.
Cihazların bu kadar sık değiştirilmesi, kullanıcıları elde tutma konusunda zorluk yaratıyor.
Kullanıcı talebini ve kod prototiplerini değerlendiren Uber, Uber Rider uygulamasına Restore Credentials desteği ekledi ve çok olumlu sonuçlar elde etti.
Bu sayede günde ortalama 4 milyon giriş işleminin ortadan kalkacağını tahmin ediyorlar ve kullanım arttıkça bu sayının da artmasını bekliyorlar.
Bu yeni politika ve uygulamanızın tek dokunuşla geri yükleme şartlarını nasıl karşılayabileceği hakkında daha fazla bilgi edinmek için lütfen bu QR kodunu ve bağlantıyı inceleyin.
Bu değişiklik Nisan 2027'de geçerli olacak. Lütfen bu tarihi takviminize ekleyin.
Uygulamanızda Kimlik Bilgilerini Geri Yükleme özelliğini uygulamaya hemen başlamak istiyorsanız Kimlik Bilgilerini Geri Yükleme becerimize erişmek için bu QR kodunu ve bağlantıyı kullanabilirsiniz.
Bu beceri, seçtiğiniz temsilciyle özelliği hızlı bir şekilde geliştirmenize veya test etmenize yardımcı olabilir.
Şimdi, dijital kimliğin bir sonraki aşamasına bakalım: Kimlik Bilgisi Yöneticisi üzerinden Dijital Kimlik Bilgileri API'si.
Dijital yeterlilik belgelerinin ne olduğunu ve nasıl çalıştığını inceleyelim.
Dijital kimlik bilgileri, kullanıcıların kendileri hakkında bilgi vermek için kullanabileceği, kriptografik olarak doğrulanabilir dijital belgelerdir.
Bu belgeler, kullanıcının cihazındaki dijital saklama alanlarında depolanır ve cihazdaki diğer uygulamalar tarafından istenebilir veya QR kodu gibi hibrit bir yöntemle gösterilebilir.
Kimlik doğrulamadan hizmetlere erişmeye ve internetten ürün satın almaya kadar çok çeşitli kullanım alanları vardır.
Dijital kimlik bilgileri, fiziksel kartlara ihtiyaç duymadan bilgi paylaşmanın güvenli ve kolay bir yolunu sunar.
Dijital kimlik bilgileri üç taraftan oluşur: veren, sahip ve doğrulayıcı.
Dijital kimlik bilgilerinin yaşam döngüsü genellikle soldan sağa doğru ilerler.
Bu varlıkların her birini ve oynadıkları rolü inceleyelim.
İlk taraf, adından da anlaşılacağı üzere kimlik bilgilerini veren taraftır. Örneğin, pasaportunuzu veren devlet bu tarafa bir örnektir.
Ancak dijital dünyada, kimlik sahtekarlığını önlemek için bu kimlik bilgileri, veren kuruluş tarafından dijital sertifikasıyla da imzalanır. Böylece kimlik bilgilerini alan herkes, bunların tam olarak kimden geldiğini bilir.
Aslında spor salonu, otel ve hatta siz bile kart veren kuruluş olabilirsiniz.
Kimlik bilgisi oluşturup imzalamanız yeterlidir.
Veren, kimlik bilgilerini oluşturur ve verir ancak bu bilgilerin bir yerde saklanması gerekir. Tıpkı resmi kimliğinizi kendi cüzdanınızda saklamanız gerektiği gibi.
Bu, bir sonraki taraf olan ve genellikle dijital cüzdan olarak da tanımlanan hamil tarafıdır.
Sahipler, adından da anlaşılacağı gibi, öncelikle verenler tarafından verilen kimlik bilgilerini saklar.
Bu belgeler cihazınızda bir uygulama olarak bulunur ve talep eden taraflara sunulabilir.
Verenler gibi, herkes sahip olabilir.
Aslında, verenlerin ve sahiplerin aynı tüzel kişi tarafından yönetilmesi yaygın bir durumdur.
Örneğin, hem kendi dijital üyelik kartını oluşturmak hem de bu kartı kendi uygulaması üzerinden yönetmek isteyen bir spor salonu düşünün.
Bu, hem veren hem de sahip olan bir kişi olur.
Üçüncü taraf, doğrulayıcı veya dijital kimlik bilgilerini isteyen taraftır.
Doğrulayıcılar, genellikle yaş şartları veya soyadı gibi kullanıcıyla ilgili özellikleri kontrol etmek için kimlik bilgisi istekleri gönderir.
Bunlar, alkol satın alma veya minimum yaş doğrulama gibi bir hizmeti gerçekleştirmek için ek kullanıcı verilerine ihtiyaç duyan işletmeler veya uygulamalardır.
Android'de bu üç taraf ile kullanıcı arasındaki etkileşimler, Dijital Kimlik Bilgileri API'si ile Kimlik Bilgisi Yöneticisi üzerinden koordine edilir.
Veren, bir kullanıcıya kimlik bilgisi vermek için API'yi çağırabilir ancak aynı tüzel kişiyseler bu işlem gerekli değildir.
Kimlik bilgisi verildikten sonra doğrulayıcı, kimlik bilgisini istemek için bir API çağırabilir.
Kimlik Bilgisi Yöneticisi, isteği mevcut tüm sahiplerle eşleştirir ve kimlik bilgisini seçip izin vermesi için kullanıcıya sunar.
Seçilen cüzdan çağrılır ve gerekirse kimlik bilgisini doğrulayıcıyla paylaşmadan önce ek kontroller yapabilir.
Doğrulayıcı, kimlik bilgilerini aldıktan sonra orijinal veren kuruluşu kontrol etmek de dahil olmak üzere kimlik bilgilerinin meşruiyetiyle ilgili çeşitli kontroller yapabilir.
Dijital yeterlilik belgelerinin tam olarak nasıl güvenli olduğunu merak ediyor olabilirsiniz.
Sürecin her adımında güvenlik önlemleri alınır. Şimdi bunlardan bazılarını inceleyelim.
Veren taraf, bir kimlik bilgisini kullanıcıyla paylaşmak istediğinde kullanıcının değiştirilemeyeceğini veya kopyalanamayacağını, yani güvenilir olduğunu doğrulamalıdır.
Bunu nasıl doğrulayabilir?
Veren kuruluş, kimlik bilgisini yayınlamadan önce, kart sahibinin kendi kimliğini ve üzerinde çalıştığı cihazın güvenliğini kanıtlamasını ister.
Kart sahibi, genellikle doğrulanabilir bir sertifika zinciri olarak cüzdan onayını gönderir.
Kart sahibi, donanıma bağlı bir anahtar çifti de oluşturur.
Veren kuruluşa, bu anahtar çiftindeki ortak anahtarı Android anahtar onayıyla birlikte gönderir. Böylece veren kuruluş, donanımın meşruiyetini doğrulayabilir.
Veren taraf, bu ortak anahtarı verilen kimlik bilgisine imzalayarak kimlik bilgisinin tek bir cihaza resmi olarak bağlanmasını sağlar.
Kullanıcı tarafında, kullanıcı yeni bir kimlik bilgisine sahip olduğunda yalnızca kimlik bilgisi meta verilerini Kimlik Bilgisi Yöneticisi'ne kaydeder.
Kimlik Bilgisi Yöneticisi, bir doğrulayıcı kimlik bilgisi isteğinde bulunduğunda hangi sahiplerin gösterileceğini belirlemek için bu meta verileri kullanır.
Kimlik Bilgisi Yöneticisi'ne hiçbir gerçek kullanıcı verisi kaydedilmez veya Google'a gösterilmez.
Kimlik Bilgisi Yöneticisi, kullanıcıya gösterilecek cüzdanları seçerken bile her cüzdanın içeriği o anda gösterilmez.
Artık bir kimlik bilgisi isteği yapıldığında ve kullanıcı bir kimlik bilgisini paylaşmaya kullanıcı izni verdiğinde seçilen cüzdan çağrılır ve iş akışı kontrolü cüzdana devredilir.
Hatırlayacağınız üzere, tutucu yalnızca bir uygulamadır. Bu nedenle uygulama çağrılır.
Bu aşamada, kart sahibi, istekte bulunan doğrulayıcı ve istenen kimlik bilgisi gibi bilgileri görebilir ve kullanıcı daha önce izin vermiş olsa bile bu kimlik bilgisini söz konusu doğrulayıcıyla paylaşıp paylaşmayacağına karar verebilir.
Kimlik bilgisi verilerine Google tarafından erişilemez.
Yalnızca yönlendirme meta verileri kaydedilir ve yük, kart sahibi ile doğrulayıcı arasında uçtan uca şifrelenir.
Bu sayede, kimlik bilgilerini hangi taraflarla paylaşmak istediğini kullanıcı belirleyebilir.
Son olarak, doğrulayıcı tarafında, kimlik bilgisi istendikten ve kullanıcı kimlik bilgisini paylaştıktan sonra doğrulayıcı, kullanıcıdan kimlik bilgisi sunumunu alır.
Doğrulayıcı, yanıtın istek için orijinal kimlik bilgisi sahibi tarafından yeni oluşturulup oluşturulmadığını kontrol edebilir.
Kimlik bilgisi yanıtının, sahibin cihaza bağlı anahtarı kullanılarak imzalandığını doğrulayabilir. Bu doğrulama, tek kullanımlık jeton istemeyi ve sahibin gözlemlediği kaynak çağrısını içerir.
Doğrulayıcı, veren sertifikasını doğrulayarak kimlik bilgisini verenin gerçekliğini de kontrol edebilir ve güvenilir bir kaynaktan geldiğinden emin olabilir.
Kısaca, verenler donanım garantisi alır, sahipler hangi kimlik bilgilerini paylaşmak istediklerini kontrol eder, doğrulayıcılar veren ve sahibin kriptografik kanıtını alır ve kullanıcılar hangi verileri paylaşmak istedikleri konusunda tam rıza sahibi olur.
Dijital kimlik bilgilerinin nasıl güvenli olduğunu ele aldığımıza göre, Android'deki Digital Credentials API aracılığıyla kullanılabilen dijital kimlik bilgilerinin bazı kullanım alanlarına göz atalım.
Ele alacağım ilk yöntem, e-posta doğrulaması.
Bu API, kullanıcının giriş yaptığı Gmail hesabını doğrudan cihazından alır ve uygulamanıza Google tarafından doğrulanmış bir dijital kimlik bilgisi olarak sunar. Böylece tek kullanımlık şifre veya sihirli bağlantı gönderme ihtiyacını ortadan kaldırır.
Bu sayede kullanıcı uygulamanızdan hiç ayrılmaz ve yalnızca tanıdık Kimlik Bilgisi Yöneticisi alt sayfasında tek bir dokunuşla izin vermesi yeterli olur.
API'nin kullanımına dair bir demo kaydını aşağıda bulabilirsiniz.
Bu, Digital Credentials API aracılığıyla e-posta doğrulaması uygulayan örnek bir uygulamadır.
"Doğrulanmış e-posta iste"ye dokunduğumda Kimlik Bilgisi Yöneticisi, cihazda bu tür kimlik bilgilerine sahip olan kullanıcılardan doğrulanmış e-posta dijital kimlik bilgisi ister.
Bu durumda, alt sayfada gösterilen doğrulanmış e-posta kimlik bilgisinin sahibi yalnızca Google'dır.
Bu, kullanıcının cihazda oturum açtığı e-posta adreslerinden biridir.
Bu durumda Google, dijital belgenin hem veren hem de sahibi konumundadır.
Paylaşmak istediğim kimlik bilgisini seçtiğimde bu bilgi uygulamaya döndürülür. Uygulama şu anda yalnızca kimlik bilgisinde yer alan alanları (doğrulanmış e-posta) gösterir.
Uygulamanızda bu bilgileri kullanarak bir sonraki uygulama ekranına geçebilirsiniz (ör. geçiş anahtarı oluşturma veya diğer hesap oluşturma adımları).
Kullanıcı için bu işlem, izin verip bir sonraki ekrana geçmek kadar basittir.
Denemek isterseniz GitHub örneğimize gidip kendi cihazınıza yükleyebilirsiniz.
Lütfen fiziksel bir cihazda kullanmayı deneyin ve cihazınızda en az bir Gmail hesabında oturum açmış olmanız gerektiğini unutmayın.
Bu nedenle, ilgilenenler varsa biraz daha zaman vereceğim.
İşte böyle.
Sizce de çok heyecan verici değil mi?
E-posta doğrulaması dendiğinde aklınıza gelen bir sonraki kullanıcı doğrulama yöntemi nedir?
Doğru, telefon numarası doğrulama.
Digital Credentials API, telefon numarası doğrulamasını da yerel olarak destekleyerek SMS OTP'lerin neden olduğu sorunları ve güvenlik açıklarını ortadan kaldırır.
Telefon numarası doğrulama işlemi de Digital Credentials API üzerinden gerçekleştirilir. Bu durumda, cihazdaki telefon numarası istenir ve dijital kimlik bilgisi olarak sunulur.
Kullanıcı, telefon numarasını paylaşmak veya doğrulamak için yalnızca tanıdık Kimlik Bilgisi Yöneticisi alt sayfasını görür. Uygulamadan çıkmadan, yalnızca birkaç dokunuşla doğrulamayı tamamlayabilir.
Burada, müşterinin uygulamadan ayrılmadan tek bir dokunuşla telefon numarasını paylaşabildiği örnek bir uygulama görebilirsiniz.
Peki, bu kurulum nasıl çalışır?
Bunu dijital kimlik taraflarıyla eşleştirirsek veren taraf, cihazın SIM kartındaki telefon numarasının operatörü, sahip ise Android Telephony olur.
Uygulamanız gibi bir doğrulayıcı, kullanıcının telefon numarasını istediğinde bu numara, Dijital Kimlik Bilgileri API çağrısıyla Google Telephony'den alınır.
Faturalandırmanın işleyiş şeklini merak ediyor olabilirsiniz.
Bu akışa özgü ek bir adım vardır. Bu adımda, kimlik bilgileri faturalandırma amacıyla operatörünüze veya toplayıcınıza iletilir.
Bu işlem, telefon numarası Google Telephony'den alındıktan sonra gerçekleşir ve şifrelenmiş bir durumda saklanır.
Bu bilgi daha sonra operatöre iletilir. Operatör, şifreyi çözüp telefon numarasını doğrudan uygulamanızın arka ucuna döndürür. Bu işlem sırasında sizden ücret alınır.
Bu yöntemin en iyi yanı, operatörün yalnızca başarılı doğrulama işlemleri için ücret almasıdır. Bu işlemler, veri veya kablosuz ağ üzerinden aktarılır ve SMS'ten çok daha güvenilirdir.
Burada, operatör toplayıcı olarak Firebase'i kullanan telefon numarası doğrulama işleminin bir demosunu görüyoruz.
Uygulama, oturum açma işleminin bir parçası olarak kullanıcının telefon numarasını istiyor.
Bu kullanıcının birden fazla SIM kartı var ve uygulamayla paylaşmak için birini seçiyor.
Kullanıcı seçimini onayladıktan sonra değişim arka planda gerçekleşir.
Ardından, alınan telefon numarasının doldurulduğu sonraki ekranı görürsünüz.
Kullanıcının uygulamadan ayrılması gerekmedi. Yalnızca birkaç dokunuşla, paylaşılacak telefon numarasını seçip onaylayarak akışta sorunsuz bir şekilde ilerledi.
Tamamlanma işlemini bir kez daha görmek için bu işlemin bitmesini bekleyin.
Bu son ekranda telefon numarasını görürsünüz.
Hepsi bu kadar.
Bugün pek çok konudan bahsettik.
İlk olarak, geçiş anahtarı uygulamanızı iyileştirmek ve şifresiz bir dünyaya geçmek için Kimlik Bilgisi Yöneticisi'ni kullanmayı inceledik.
Daha fazla bilgi edinmek ve örnek uygulamalarımıza erişmek için lütfen buradaki Kimlik Bilgisi Yöneticisi ve geçiş anahtarları ile ilgili kaynaklarımıza göz atın.
Ardından, uygulamalarınız için yakında zorunlu hale gelecek olan ve kullanıcılarınızın yeni bir cihaz kurarken sorunsuz bir şekilde oturum açmasını sağlayan tek dokunuşla oturum açma özelliğini ele aldık.
Bu, Nisan 2027'ye kadar Google Play Store'da zorunlu hale getirilecek. Lütfen bu tarihi takviminize ekleyin.
Son olarak, dijital kimlik bilgilerinin işleyiş şeklini ve Android'deki en kullanışlı özelliklerinden bazılarını ele aldık.
İçeriği daha ayrıntılı incelemek ve örneklerimize erişmek için lütfen dijital kimlik bilgileriyle ilgili kaynaklarımıza buradan göz atın.
Bugün paylaştığımız her şey kullanıma hazır.
Android'de kimliğin geleceği burada ve her zamankinden daha heyecan verici.
Zaman ayırdığınız için teşekkürler. Öğle yemeği vakti geldi, dışarıda yemek yiyebilirsiniz.
Geçiş anahtarları veya dijital kimlik bilgileriyle ilgili sorularınız olursa bana ya da Tom'a sormaktan çekinmeyin.
Hoşça kalın.
val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
requestJson = registerRequestJson
)
val createCredentialResponse = credentialManager.createCredential (
context = localActivity,
request = createPublicKeyCredentialRequest
)val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
requestJson = authenticationRequestJson
)
val signInRequest =
GetCredentialRequest(listOf(getPublicKeyCredentialOption))
val result = credentialManager.getCredential (
context = localActivity,
request = signInRequest
)val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
requestJson = registerRequestJson,
preferImmediatelyAvailableCredentials = false,
isConditional = true
)
val createCredentialResponse = credentialManager.createCredential (
context = localActivity,
request = createPublicKeyCredentialRequest
)