İnternet kimlik sağlayıcı servislerinin kullanım durumlarının sistematik incelenmesi ve ilgili tasarım paradigmalarının değerlendirilmesi
Systematic review of use cases of internet identity provider services and evaluation of related design paradigms
Yazar: MURAT GÜMÜŞ
Danışman: PROF. DR. KEMAL BIÇAKCI
İstanbul Teknik Üniversitesi / Bilişim Enstitüsü / Bilişim Uygulamaları Ana Bilim Dalı / Bilgi Güvenliği Mühendisliği ve Kriptografi Bilim Dalı
Derece: Yüksek Lisans, 2024
Konu: Bilgisayar Mühendisliği Bilimleri-Bilgisayar ve Kontrol = Computer Engineering and Computer Science and Control

Özet:
İnternetin yaygınlaşmasıyla beraber günlük hayatımızda yüzlerce web sitesinden ve uygulamadan faydalanmaya başladık. Bu sitelerin birçoğu ise kullanıcılara hizmet verebilmek için üye olmamızı talep etmektedir. Dolayısıyla bir kullanıcı internet servislerinden faydalanmak için onlarca hesaba ve parolaya ihtiyaç duymaktadır.  Son araştırmalara göre kullanıcılar 50 – 80 farklı sitede üyelik bulundurmaktadırlar, bu sebeple ya aynı parolaları farklı sitelerde kullanarak bir güvenlik sorunu ile karşı karşıya kalmakta ya da onlarca parolayı saklamak ve güncellemek zorunda kalmaktadırlar.

Bahsedilen zorluklar ise günümüzün popüler teknolojilerinden tekil oturum açma mekanizmalarının yolunu açmış oldu. Tekil oturum açma mekanizmaları ile kullanıcılar tek bir kimlik sağlayıcı hesabı ile birçok siteye giriş yapabilmekte ve her seferinde yeni bir hesap yaratma ve bu hesapları yönetme ihtiyacından kurtulmaktadırlar.  Çalışmamızda söz konusu tekil oturum açma mekanizmalarının en yaygınlarından olan OAuth 2.0 protokolü ve OAuth 2.0 protokolü ile birlikte çalışan OIDC 1.0 protokolünü incelenmiştir. 

OAuth 2.0, istemci uygulamalarının, bir yetkilendirme sunucusu tarafından sağlanan erişim jetonunu kullanarak, veri sahibinin (genellikle bir kullanıcı) izniyle korunan verilere erişmesine olanak tanıyan bir protokoldür. Protokol dört adet rol içerir: veri sahibi (kullanıcı), veri sunucusu (korunan verileri barındıran sunucu), istemci uygulaması (korunan verileri talep eden uygulama) ve yetkilendirme sunucusu (veri sahibini doğrulayan ve verilere erişimi sağlayan sunucu). OAuth 2.0 Protokolü veri sahiplerinin çeşitli web sitelerini kullanırken Apple ve Google gibi kimlik sağlayıcı hesaplarını kullanmasına olanak sağlar. 

Bu çalışmada, kimlik sağlayıcılar hem son kullanıcı perspektifinden hem de istemci uygulamaları açısından incelenmiştir. İlk olarak kimlik sağlayıcılar kullanışlılık ve gizlilik açısından değerlendirildi. Sonrasında ise kimlik sağlayıcıların istemci uygulamaları doğrularken talep ettiği gereksinimlere odaklanıldı. Kimlik sağlayıcılar OAuth 2.0 Protokolünü uygularken birçok farklı yaklaşım kullanmaktadır, bu farklılıklar kategorize edildi. 

Kimlik sağlayıcılar kullanıcı parolalarını ve bilgilerini sakladıkları için, kullanıcıların verilerinin korunmasında temel bir rol oynamaktadır. Bu verilerin istemci uygulamaları ile nasıl paylaşıldığı üstünde çalışıldı. Bu çalışmayı yaparken başlıca kimlik sağlayıcıları ele aldık ve kullanım alanlarını ortaya çıkarmaya çalıştık. Söz konusu kullanım alanları temel, önerilen ve genişletilmiş  olarak kategorilere ayrıldı.

Çalışmamızda hem kullanıcı-kimlik sağlayıcı ilişkileri açısından hem de kimlik sağlayıcı-istemci uygulamaları açısından önemli eksiklikler tespit edildi. Kimlik sağlayıcılar, istemci uygulamalarının OAuth 2.0 protokolünün eski versiyonlarından gelen ve bilgi güvenliği konusunda zafiyetlere yol açan implementasyon tiplerini kullanmasına izin vermeye devam etmektedir. Ayrıca her ne kadar kullanıcılar verilerinin istemci uygulamaları ile paylaşılmasına rıza gösterseler de e-posta adresi gibi veriler rıza kapsamının dışında reklam faaliyetleri ya da sosyal mühendislik çalışmalarında kullanılmak üzere istemci uygulamalar tarafından yetkisiz uygulamalar ile de paylaşılabilmektedir. Rastgele üretilen sahte e-posta adresi gibi uygulamalar en kısa zamanda yaygınlaşmalıdır. Söz konusu eksiklikler ile ilgili olarak kimlik sağlayıcılar tarafından iyileştirme çalışmalarının yapılması elzemdir.

Abstract:
With the widespread use of the internet, people have started to benefit from dozens of websites and applications in their daily lives. Many of these websites/applications require users to register to benefit these services. Therefore, a user needs dozens of accounts and passwords to use internet services. According to recent research, an average user has memberships on 50-80 different sites, so they either face a security problem by using the same passwords on different sites or have to store and update dozens of passwords.

These difficulties have paved the way for single sign-on mechanisms, which are popular technologies of today. With single sign-on mechanisms, users can log in to many sites with a single identity provider account and get rid of the need to create new accounts and manage these accounts every time. In this thesis, it is examined the one of the most prevalent single sign-on mechanisms, OAuth 2.0 protocol and OIDC 1.0 protocol that work with OAuth 2.0 protocol.

OAuth 2.0 is a protocol that enables client applications to access protected data with the permission of the data owner (usually a user) using an access token provided by an authorization server. The protocol includes four roles: resource owner (user), resource server (server hosting protected data, data server), client application (application requesting protected data, relying party), and authorization server (verifies the data owner and provides access to the data). The OAuth 2.0 protocol allows data owners to use identity provider accounts such as Apple and Google while using various websites.

The OAuth 2.0 protocol allows different grant types that determine how account credentials are issued to relying parties (client applications). Each grant type is meant to fulfill distinct use cases. There are seven flow types in OAuth 2.0 protocols, these are: authorization code flow, implicit flow, authorization code flow+PKCE, client credentials flow, resource owner password flow, device flow, and hybrid flow.

OIDC 1.0 is a protocol that works on top of the OAuth 2.0 protocol and it allows an identity provider to authenticate users to a relying party. OIDC protocol uses a special "openid" value to scope parameter for specifying intent to authenticate. The protocol enables third-party apps to authenticate the identity of the end-user and get basic user profile data. OIDC uses JSON Web tokens (JWT). JWT include claims about entities such as user names, email addresses, and additional data. This specification defines a set of standard claims. They can be requested to be returned either in the UserInfo Response or in the ID Token.

In this study, it is examined identity providers from both the end-user perspective and the client application perspective. First, identity providers were evaluated in terms of usability and privacy. Afterward, we focused on the requirements that identity providers request when authenticating and authorizing client applications. Identity providers use many different approaches while implementing the OAuth 2.0 Protocol, these differences were categorized. Identity providers play a vital role in protecting users' data because they store user passwords and data scopes. We worked on how this data is shared with client applications. While conducting this study,  the major identity providers were examined and tried to reveal their use cases. Categories were divided into three: basic, recommended, and extended use cases.

Cognitive walkthrough method and heuristic evaluation were performed for usability assessment. With this methods, it is more convenient to find errors or impractical interface designs. We can categorize our contributions into four:
 a.	Identification of identity providers use cases: it is identified thirteen use cases and categorized into three; essential, recommended, and extended.
b.	Finding design paradigms in identity providers: it is found 36 design paradigms related to identified use cases. These design paradigms consist of existing features and proposed features.
c.	Comparing the most common 6 identity providers in the scope of the use cases: it is worked on six major identity providers and tried to emphasize usability and privacy issues.
d.  Revealing the requirements for authenticating a relying party to identity providers.
e.  Finding differences among major identity providers in the implementation of the protocols.

In our study, significant drawbacks were identified both in terms of user-identity provider relationships and identity provider-client applications. It was discovered that IDPs still allow legacy flows. The existence of legacy flows gives rise to security risks. The OAuth standards undergo updates, and the OAuth Working Group publishes security guidelines regularly. However, it has been observed that some Identity Providers (IDPs) do not fully adhere to these specifications and security practices. The main issue primarily arises from the existence of legacy flows. In 2012, the Working Group released OAuth 2.0, which introduced the authorization code flow. Subsequently, in 2015, the PKCE flow was launched. However, despite these advancements, the implicit flow is still observed, and some identity providers continue to support the resource owner password flow. These legacy flows are deprecated in 2023 with the OAuth 2.1 Specification Draft version.  However, it is important to note that there is currently no enforcement mechanism for IDPs. To ensure that IDPs adhere to current OAuth requirements, an approach should be proposed. Despite the continuous updates to the protocol, the absence of a compelling driving force in the implementation process results in a failure to successfully apply these upgrades.
Another major drawback is although users consent to share their data sets with client applications, data such as email addresses can be shared with unauthorized applications by client applications for advertising or social engineering purposes outside the scope of consent. Techniques such as randomly generated pseudo-email addresses should be widespread as soon as possible. 

Additionally, IDPs should strive to disclose end-user data at a minimum level. The majority of the IDPs also do not permit users to choose data scope, users should have the opportunity to select their data scope that is shared with RPs. It is essential that identity providers carry out improvement studies regarding these deficiencies.