OAuth 2.0 ve OIDC (OpenID Connect) Nedir?

Published in

SDTR

6 min readSep 6, 2021

Herkese Merhaba,

Bu yazımda uygulamalarımızın olmazsa olmazı yetkilendirme işlemlerinde protokol (sektör standardı) olarak kullanılan OAuth2.0'dan ve onun üstüne geliştirilmiş (ilgili protokol üstüne eklenmiş bir katman) ve kimlik doğrulama işlemlerinde kullanılan OIDC (Open Id — Connect) protokolünden bahsetmek istiyorum.

OAuth 2.0 — OIDC Nedir ve Ne İçin Kullanılır?

OAuth 2.0, Authorization; OIDC (OpenID Connect) ise Authentication için kullanılan sektör standartlarıdır.

Hepimiz günlük hayatta birden fazla web veya mobil uygulama kullanarak işlerimizi yerine getiriyoruz. Her bir uygulama için yeni kullanıcı bilgileri tanımlamak, bunlarla ilgili şifreleri aklımızda tutmak bir noktadan sonra zor bir hal alıyor. Bazı şifre yönetim uygulamaları işin için dahil oluyor vs.

Bu zorluğu ortadan kaldırmak için 2005 yılında Brad Fitzpatrick, OpenID adı verilen bir kimlik doğrulama protokolü geliştirdi.[1]

Geliştirilen bu protokolün temel amacı, kullanıcıların merkezi bir sistem/uygulama üzerinden (örneğin, Google) ilgili kullanıcı bilgilerini tanımlamaları ve bu protokolü kullanan diğer uygulamaların kullanıcıların sadece gerekli gördükleri ve kritik olmayan bilgilerini (güvenlik riski temsil etmeyen bilgilerini) kullanarak ilgili işlemlerini yerine getirebilmelerini sağlamaktı. Ve bu işlem sertifikalar aracılığıyla yapılmaktaydı.

Bu geliştirilmiş olan protokol, açık bir protokol durumunda değildi ve aynı zamanda ilgili işlemleri sertifikalar aracılığı ile yapmaktaydı. 2007 yılında kurulan OAuth Discussion Group, açık bir kimlik doğrulama protokolü ortaya koymak için kolları sıvadı. 2007 yılının Aralık ayında v1.0 olarak ilgili protokol açık bir şekilde kullanıma sunuldu ve Ekim 2012'de ise OAuth 2.0 olarak son halini aldı.

Bu sayede, OpenID’de boş kalan Authorization (yetkilendirme) boşluğunu OAuth 2.0'ın token lı yapısı sayesinde uygulamalar doldurmaya başladı. Bu sayede artık işlemler sertifikalar yerine token lar aracılığı ile yerine getirilmeye başlandı.

Daha sonra yıl 2014 ü gösterdiğinde ise OAuth 2.0 Framework ü üzerinde geliştirilen OIDC (OpenID Connect) adında bir identity katmanı eklendi ve bu sayede Authentication (kimlik doğrulama) işlemleri de bir standart bünyesinde tanımlanmış oldu.

OAuth 2.0 Yapısı

Yukarıdaki görselde OAuth 2.0'ın temel yapısını görmekteyiz. En temel manada, biz kullanıcı olarak (Resource Owner) kendi verilerimize erişmek istediğimizde ilgili websitesine girer (Client) ve ilgili url e istekte bulunuruz. İlgili websitesi o kaynağa erişimimiz olup olmadığını sorgulamak için Authorization Server ile iletişim kurararak bunu sorgular. Bunun sonucunda, ilgili sunucu kullanmış olduğumuz uygulamaya yetkimizin olduğunu belirtir ve bunun sonucunda erişmek istediğimiz bilgilerimize Resource Server ın döndüğü sonuç neticesinde ulaşmış oluruz.

Burada adı geçen Resource Owner, Client, Authorization Server ve Resource Server OAuth2.0 tarafından tanımlanan Roller’dir.

OAuth 2.0 birbirinden farklı kullanım koşullarına göre değişik çapta Authorization Flow’lar sunmakta ve bu akışlar aşağıdaki gibi adlandırılmaktadır.

Authorization Code Flow
Implicit Flow
Resource Owner Password Credential Flow
Client Credential Flow

Authorization Code akışı, Server Side uygulamalarda; Implicit Flow ise Browser Based uygulamalarda (SPA uygulamalarında) sıklıkla kullanılmakta.

Bu akışlarda, temel mantık aynı olmakla birlikte (authorization sağlanması, token değiş-tokuşu vb.) uygulanan adım sayıları ve yöntemleri farklıdır. Örnek olması açısından sıklıkla kullanılan Authorization Code Flow’u ilgili endpointler ile birlikte inceleyelim.

Örnek: OAuth 2.0 — Authorization Code Flow

Bu akışı temel olarak 4 adım altında inceleyebiliriz.

1-) Authorization Request

İlgili isteği inceleyecek olursak, client_id diye bir query param geçtiğimizi görebiliriz. Bu client_id bizim uygulamamızın OAuth 2.0 protokolü dahilinde tanımlanmış halini gösterir. Yani ilgili uygulamayı tanımlayan bir değerdir. Scope parametresi ise ilgili yetkilendirmesinin kapsayacağı alanı belirtir. Yani kullanıcı için yukarıda resource ve profile kapsamındaki ilgili bilgileri görmesine izin vardır. Bunlar dışındaki diğer kısımlara generate edilecek token ile ulaşamaz. Redirect_uri ise kullanıdığımız uygulamanın ilgili token i karşılayıp kullanacağı web-sitesini temsil eder.

Buradaki en önemli parametre olan response_type parametresi ise yapmakta olduğumuz isteğin hangi flow ile yapılacağını gösterir. (Authorization Code Flow için “code”)

İlgili istek iletildikten sonra kullanıcının giriş yapmaması veya kullandığı token ın süresinin bitmesi durumunda ilgili giriş ekranına yönlendirilerek giriş yapması sağlanır.

2 -) Authorization Response

Authorization Server ilgili isteğin geçerli ve doğru formatta olduğundan emin olduktan sonra, istekte belirtilmiş olan ilgili callback url’e (redirect_uri) Authorization Code ile birlikte bir GET isteği atar.

3 -) Token Request

Authorization Code elde edildikten sonra ilgili Access Token’ı elde etmek için ilgili Authorization Code kullanılarak bir token isteğinde bulunulur.

Bu istekte görüleceği üzere grant_type olarak Authorization Code belirtiliyor ve bu isteğin başarılı olması durumunda yönlendirilecek yer redirect_uri parametresinde belirtiliyor.

4 -) Token Response

Yapmış olduğumuz Token Request’i başarı ile sonuçlanır ise aşağıdakine benzer bir Token Response ilgili Client tarafından kullanılabilir.

Artık bu access_token sayesinde, kullanıcı Client üzerinden ilgili Resource Server’daki verilerine ulaşabilir.

Burada eğer istek sonucunda refresh_token bilgisi de dönmüş ise, access_token’ın süresi dolunca bu token ile birlikte ilgili access_token’ın yenilenmesi için istekte bulunulabilir.

OIDC (OpenID Connect) Yapısı

Simple identity layer on top of the OAuth 2.0 protocol.

OpenID Connect, OAuth 2.0 protokolünün Authentication için kullanılmasını sağlamak amacıyla OAuth 2.0 protokolünün üstüne eklenmiş bir identity layer olarak düşünülebilir.

OpenID Connect, bir metadata dökümanı içerir (.well-known/openid-configuration) ve bu döküman bir uygulama aracılığıyla giriş yapmak için gerekli olan bilgileri tanımlar. (Hangi url’lere istek yollanmalı, hangi scope ları içeriyor vs.)

Eğer ilgili metadata dökümanını görüntülemek isterseniz, https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration adresine giderek Microsoft’un OIDC metadata dökümanına ulaşabilirsiniz.

OAuth 2.0'da olduğu gibi OIDC’de de akışlar kullanılarak işlemler gerçekleştirilir. Örnek olması açısından OAuth 2.0'da olduğu gibi OIDC için de Authorization Code Flow’un endpointlerini inceleyelim.

Örnek: OpenID Connect — Authorization Code Flow

Bu akışı temel olarak 6 adım altında inceleyebiliriz.

1 -) Authentication Request

İlgili endpoint i inceleyecek olursak scope bölümünde openid diye bir değerin geçildiğini görebiliriz. Bunu aslında OIDC’yi tanımlarken kullandığımız identity layer kavramının karşılığı olarak düşünebiliriz. OAuth 2.0 protokolüne eklenen bu scope ile birlikte artık Authorization Server ilgili isteği OIDC kapsamında ele alır.

2 -) Authentication Response

Burada OAuth 2.0'da olduğu gibi callback-url'e (redirect-uri) Authorization Code ile birlikte bir GET isteği atılır. Bu sayede Client ilgili authorization code’dan haberdar olmuş olur.

3 -) Token Request

Daha sonra ise ilgili Client, elde ettiği authorization_code ile birlikte Authorization Server’a token isteğinde bulunur. (İlgili Authorization_Code ile Access_Token değiş tokuşu sağlanır.)

4 -) Token Response

Burada dönen değerleri inceleyecek olursak, id_token adında bir alanın olduğunu görebiliriz.

ID_Token: Kimlik kartı olarak düşünülebilir. Son kullanıcı hakkında bilgiler içerir. JWT formatındadır. OIDC’nin OAuth 2.0'a getirdiği eklenti olarak düşünülebilir. Bu sayede Authentication işleminin gerçekleşmesi sağlanıyor.

5 -) UserInfo ile Son Kullanıcının Bilgilerinin Alınması

UserInfo endpointi, giriş yapmış kullanıcı hakkındaki bilgileri döner. (ad, soyad vb.) Client ilgili kullanıcının bilgilerine ihtiyaç duyduğunda bu endpointi kullanarak gerekli bilgileri elde edebilir. (Burada ilgili kullanıcının artık authenticate edildiğine ve Bearer Authorization ile ilgili endpointe istekte bulunulduğuna dikkat edelim.)

6 -) UserInfo Response — Son Kullanıcının Bilgileri

İlgili isteğin başarılı dönmesi ile birlikte, kullanıcının bilgilerine ulaşılır. Bir diğer yöntem olarakta daha önce generate edilmiş Id_Token değeri decode edilerek, kullanıcının ilgili bilgilerine ulaşılabilir.

Okuduğunuz için teşekkürler. Bir dahaki yazıda görüşmek dileğiyle…