OAuth 2.0 & OpenId Connect Simplified

OAuth 2.0 bir kullanıcının bir uygulamaya farklı uygulamadaki verilerine erişmesi için izin verdiği güvenlik standardıdır. OAuth 2.0 protokolü yalnızca authorization işlemlerini gerçekleştirmek üzere tasarlanmıştır. OpenID Connect, OAuth 2.0 protokolü üzerine kurulan ince bir kimliklendirme katmanıdır. Uygulamaya giriş yapan kullanıcıyı doğrulamayı ve temel profil bilgilerinin elde edilmesini sağlar. OIDC katmanı authentication işlemlerini gerçekleştirir.

OAuth 2.0

Open Authorization yetkilendirme işlemlerinde kullanılan bir protokoldür. Bir uygulamanın bir kullanıcı adına farklı bir uygulama kaynağına verilen izinlerle güvenli şekilde erişmesini tanımlar. Erişim access token üzerinden gerçekleşmektedir. Yetkilendirme sürecinde resource owner credential bilgilerini client ile paylaşmaz. Bu işleme Facebook ve Google ile giriş yapmak örnek verilmektedir. OAuth 1.0 üzerine 2012 yılında OAuth 2.0 çıkmıştır.

Görselde iki uygulama görülmektedir. Application, AnotherApp üzerinden kullanıcı bilgilerine erişmek istemektedir. OAuth protokolü olmaksızın kullanıcı bilgilerine erişmeye çalışalım. Bu durumda Application istediği bilgilere erişmek için AnotherApp bünyesindeki kullanıcı credential bilgilerine ihtiyaç duymaktadır. Bu durum kullanıcı, Application ve AnotherApp için arzu edilen bir sonuç değildir. OAuth 2.0 protokolü bu soruna çözüm getirerek yetkinin güvenli şekilde delegasyonunu sağlar. Application kullanıcının credential bilgilerini talep etmeksizin kullanıcıyı AnotherApp yetkilendirme sayfasına yönlendirir. Yetkilendirme sırasında Application‘ın bir takım bilgilere erişim izni istediği sorulmaktadır. Application yetkilendirildiğinde bir authorization code elde eder. Bu kod ile access token elde ederek resource server kaynaklarını izinleri kapsamında tüketir.

OAuth 2.0 bir authorization protokolüdür. Authentication işlemlerinde OpenID Connect protokolü görev alır.

OAuth Roles

OAuth 2.0 protokolü kullanıcı ve uygulamalar için dört adet rol tanımlar. Protokol kapsamında birbirleriyle haberleşecek tarafları tanımlar.

• Resource owner kişi ve uygulama olabilmektedir. Resource server bünyesinde barındırılan verinin sahibi ve bu veriye erişim izni veren taraftır. Uygulamaların birbirleriyle veri alışverişi yaptığı durumlarda bu varlık kişi yerine uygulama olmaktadır.
• Resource server korunan verilerin barındırıldığı sunucudur.
• Client resource owner adına resource server bünyesinde korunan verilere erişim talebinde bulunan uygulamalardır.
• Authorization server veri kaynağına erişmek isteyen client uygulamalarını yetkilendiren suncudur. Resource owner başarıyla kimliğini doğruladığında client uygulamasını yetkilendirerek access token dönmektedir. Bazen Resource server ve authorization server aynı sunucuda olabilmektedir.

OAuth Terminology

OAuth 2.0 protokolünde kullanılan terimler hakkında bilgi edinelim.

• Authorization grant client uygulamasının access token elde etme yöntemidir.
• Authorization code yetkilendirme işlemi sırasında client uygulamasına verilen geçici bir koddur. Client bu kodu kullanarak access token alır.
• Redirect uri resource owner client uygulamasını yetkilendirdiğinde authorization server tarafından tekrar yönlendirileceği adrestir.
• Response type client uygulamasının almayı beklediği bilgi türüdür. Yaygın olarak authorization code kullanılmaktadır.
• Access token client uygulamasının resource server ile iletişim kurmak için kullanacağı bilgi kümesidir.
• Refresh token client uygulamasının access token ömrü dolduğunda yeni bir tane edinmesini sağlayan bilgidir.
• Scope client uygulamasının resource server verilerine erişmek üzere istediği izinlerdir.
• Consent resource owner‘ın resource server‘a yönlendirilmesiyle hangi client uygulamasının hangi izinlerle yetkilendirileceğidir.
• Front channel yetkilendirme akışının browser üzerinde gerçekleşen ve gözlemlenen kısmıdır. Bu kısım kullanıcının authorization server‘a yönlendirilmesi, consent ile client uygulamasının yetkilendirilmesi işlemlerinden oluşur. Back channel‘a göre daha az güvenlidir.
• Back channel yetkilendirme akışının arkaplanda http istekleriyle gerçekleşen kısmıdır. Client uygulamasının resource server üzerinden access token alması, resource server ile haberleşmesi işlemlerinden oluşur.

OAuth Grant Types

OAuth 2.0 protokolünde tanımlı beş adet yetkilendirme türü bulunmaktadır.

Authorization Code Grant

Yetkilendirme türleri arasında en yaygın kullanılan türdür.

Client uygulaması resource owner adına resource server bünyesindeki bilgilere erişmek istemektedir. Client uygulaması resource owner‘i gerekli bilgileri query string parametrelerine ekleyerek authorization server‘a yönlendirir. (1)

(GET) /authorize?
    response_type=code&
    client_id=abc123&
    redirect_uri=/callback&
    scope=profile&
    state=foobar

Yetkilendirme işlemiyle resource owner client uygulamasının talep ettiği bilgilere erişim izni vereceği consent sayfasına yönlendirilmektedir. (2)

/callback?
    error=access_denied&
    error_description=User did not consent

/callback?
    code=oMsCeLktyu56mtpg5u7&
    state=foobar

Client uygulaması yetkilendirildiğinde bir authorization code üretilerek önceki istekte belirtilen redirect_uri‘ye geri gönderilmektedir. (3)

(POST) /token
{
    client_id: abc123,
    client_secret: secret,
    redirect_uri: /callback,
    grant_type: authorization_code,
    code: oMsCeLktyu56mtpg5u7,
}

Sonrasındaysa client uygulaması authorization code karşılığında acccess token edinerek resource server kaynaklarını izinleri doğrultusunda tüketir. (4-5)

Implicit Grant

Bu yetkilendirme türü JavaScript gibi client-side uygulamalarına yönelik akıştır. Uygulama kaynak kodları erişilebildiğinden içerisinde client secret bilgisini tutmamalıdır. Ekstra authorization code değişimi olmaksızın client uygulamasına hemen access token dönülmektedir.

Client uygulaması resource owner adına resource server bünyesindeki bilgilere erişmek istemektedir. Gerekli bilgiler query string parametrelerine eklenerek authorization server‘a yönlendirilmektedir. (1)

(GET) /authorize?
    response_type=token&
    client_id=abc123&
    redirect_uri=https://cdn.burakneis.com/callback&
    scope=profile&
    state=foobar

Resource owner client uygulamasını yetkilendirmek üzere consent sayfasına yönlendirilmektedir. (2) Client uygulamasının yetkilendirilmesiyle yönlendirme adresiyle geriye access token dönülmektedir. (3) Sonrasındaysa client uygulaması access token ile resource server kaynaklarını tüketir. (4)

Client Credentials Grant

Bu akış kullanılarak client uygulaması credential bilgilerini authorization server‘a sunarak bir access token edinmektedir.

Client uygulaması resource server bünyesinde sahip olduğu korunan kaynaklara erişmek için credential bilgilerini sunar. (1)

(POST) /authorize
Authorization: Basic base64Encode(client_id:client_secret)
{
    grant_type: client_credentials,
    scope: profile
}

Authorization server client credential bilgilerini doğrulayarak bir access token döner. (2)

Resource Owner Password Credentials Grant

Bu akış resource owner ile client uygulaması arasında güven ilişkisi olduğu durumlarda tercih edilmelidir. Bir hizmetin kendi mobil uygulaması gibi. Yalnızca öteki akışlar uygun olmadığında izin verilmelidir.

(POST) /authorize
{
    client_id: abc123,
    client_secret: secret,
    grant_type: password,
    scope: profile,
    username: burak,
    password: password
}

Client uygulaması resource owner, credential bilgilerini (kullanıcı adı ve şifre) edinmekte. Sonrasındaysa bu bilgilerle authorization server‘a POST isteği gönderir.

Refresh Token Grant

Bu akışta ömrü dolan access token bir refresh token kullanılarak yenilenmektedir.

(POST) /authorize
{
    grant_type: refresh_token,
    refresh_token: aE8uB1nmEer12hJ3,
    client_id: abc123,
    client_secret: secret,
    scope: profile
}

Client uygulaması authorization server‘a bir POST isteği göndererek access token’ı yeniler.

OpenID Connect

OpenID, OAuth protokolü üzerine kurulmuş bir identity katmanıdır. Identity yetkilendirilmiş kullanıcı hakkındaki bilgilerdir. OAuth, aralarında bağ bulunmayan farklı uygulamaların kimlik bilgilerinden haberleri olmaksızın izin verilen kaynaklara yetkileri doğrultusunda ne şekilde erişeceğinin tanımlandığı protokoldür. OpenID, client uygulamalarının Authorization server tarafından yetkilendirilen kullanıcıların kimliğinin doğrulanmasını sağlar. Kullanıcı hakkındaki temel profil bilgilerini REST API üzerinden sunar.

OIDC destekleyen Authorization Server Identity Provider olarak adlandırılmaktadır. OIDC katmanı Single sign-on (SSO) özelliğini etkinleştirerek uygulamalar arasında oturumun taşınmasını da sağlar.

OpenID Roles

Bu katmandaki taraflar hakkında bilgi edinelim.

• End user kimlik bilgileri talep edilen varlıktır. OAuth 2.0 protokolünde resource owner olarak geçer. Sahip olduğu kaynaklardan biride kendi kimliğidir.
• Relying party kullanıcı kimliklerinin doğrulanması ve kullanıcı hakkındaki claim listesine istekte bulunmak için identity provider‘a dayanan client uygulamasıdır.
• Identity provider authentication işlemlerini gerçekleştiren authorization server‘dır. Relying party tarafına end-user kimliğinin doğrulanmasını sağlayarak end-user ile ilgili claim listesini sunar.

Identity provider relying party‘nin ihtiyaç duyduğu bu işlemleri ID Token kullanarak gerçekleştirir. İçerisinde kullanıcının nasıl authenticate edildiği ve ihtiyaç duyulan claim bilgileri bulunur. Bu claim listesi aşağıdaki gibidir.

• Subject Identity provider tarafından kullanıcıya atanan unique-identifier.
• Issuing authority token‘i yayınlayan identity provider.
• Audience token‘i hangi relying party‘lerin kullanabileceğini tanımlar.
• Issue date token‘in yayınlandığı tarihtir.
• Expiration date token‘in geçerli olacağı tarihtir.
• Authentication time end-user kimliğinin doğrulandığı tarihtir.
• Nonce reply-attack‘larını önler.

Access token gibi ID Token‘da bir JWT’dir ve dijital olarak imzalanmıştır. OIDC bilgi edinmek için claim ve scope‘ları kullanır. OpenID spesifikasyonunda tanımlı birkaç claim (name family_name given_name middle_name nickname, email address phone gender birthdate picture website zoneinfo locale ve updated_at) ve beş scope (openid profile email address phone) bulunmaktadır. Bir scope belirli claim‘lerin gruplanmasıyla (profile gibi) oluşabilir.

openid scope’u kullanıcı kimliği doğrulanırken OpenID Connect kullanılacağını belirtir.

OpenID Endpoints

İlk kimlik doğrulama isteğinde client uygulaması identity token içerisinde bir takım scope ve claim bilgilerinin dönmesini isteyebilir. Alternatif olarak bu bilgiler UserInfo endpoint’ine access token kullanılarak istekte bulunmasıyla da elde edilebilir. OpenID Connect Identity Provider client uygulaması ve end-user‘in etkileşimde bulunduğu bir takım endpoint’lere sahiptir.

• Authorization endpoint end-user‘in kimliğini doğrulaması ve client uygulamasına identity bilgilerine (email, adres gibi) erişim izni vermesinin istendiği yerdir. İzin verildiğinde bir authorization code döner. End user‘in bir user-agent kullanarak dolaylı yoldan Identity provider ile etkileşime girdiği endpoint’tir.
• Token endpoint client uygulamasının kimliğini doğrular. Authorization endpoint’i üzerinden alınan authorization code karşılığında identity token, access token ve isteğe bağlı refresh token verir.
• UserInfo endpoint geçerli bir access token sunulmasıyla izin verilen identity ve claim bilgilerini client uygulamasına döndürür.

OpenID Flow

OpenID Connect üç akış tanımlar. Authorization Code ve Implicit akışları aynı isme sahip OAuth akışlarını temel alır. OAuth protokolünden farkı bir ID Token üretiliyor olmasıdır. Hybrid akış Authorization Code ve Implicit akışlarının birleşimidir.

Authorization Code Flow

Bu akış belirtildiği üzere en yaygın kullanılan türdür.

Relying party bünyesinde yetkilendirmeye tabi içeriğe ulaşmak isteyen end-user gerekli bilgileri query string parametrelerine ekleyerek Identity Provider authorization endpoint’ine yönlendirilir. (1)

(GET) /authorize?
    response_type=code&
    scope=openid profile&
    client_id=abc123&
    redirect_uri=/callback&
    state=foobar

Scope içerisinde kullanılan openid bunun bir OpenID Connect kimlik doğrulaması ve ID Token için bir istek olduğunu belirtir. Kimliğin doğrulanmasıyla end-user relying party‘nin talep ettiği identity bilgilerine erişim izni vereceği consent sayfasına yönlendirilmektedir. (2) Relying party yetkilendirildiğinde bir authorization code üretilerek önceki istekte belirtilen redirect_uri‘ye geri gönderilmektedir. (3)

(POST) /token
Authorization: Basic base64Encode(client_id:client_secret)
{
    redirect_uri: /callback,
    grant_type: authorization_code,
    code: oMsCeLktyu56mtpg5u7
}

Sonrasındaysa relying party token endpoint’ine istek atarak authorization code karşılığında ID Token, access token ve isteğe bağlı refresh token edinir. (4) Scope kapsamında profile bilgisi istediğinden access token ile userinfo endpoint’ine gidererek ihtiyaç duyduğu bilgileri edinir. (5)

Implicit Flow

Bu akışta iki senaryo vardır. Client uygulaması ID ve access token isteyerek access token ile UserInfo endpoint’inden ihtiyaç duyduğu bilgileri edinir. İkinci senaryoda client uygulaması yalnızca bir ID Token isteyerek ihtiyaç duyduğu bilgilerin token içerisinde gönderilmesini ister.

Relying party bünyesinde yetkilendirmeye tabi içeriğe ulaşmak isteyen end-user gerekli bilgileri query string parametrelerine ekleyerek authorization endpoint’ine yönlendirilir. (1)

(GET) /authorize?
    response_type=id_token token&
    scope=openid profile&
    client_id=abc123&
    redirect_uri=/callback&
    state=foobar

End-user, relying party uygulamasını yetkilendirmek üzere consent sayfasına yönlendirilmektedir. (2) Relying party yetkilendirildiğinde yönlendirme adresiyle geriye id token ve access token dönülmektedir. (3) Relying party, access token ile userinfo endpoint’ine giderek istediği bilgileri elde eder. (4)

Hybrid Flow

Bu akış Authorization Code ve Implicit akışlarının birleşimidir. Token bilgileri hem authorization hem de token endpoint’leri üzerinden elde edilebilmektedir. Token bilgilerinin nereden elde edileceği Response Type üzerinden belirtilmektedir. Response Type hem code token hem code id_token hem de code id_token token olabilmektedir.

Client uygulaması code ve id_token kombinasyonunu kullanırsa gerektirdiği scope bilgileriyle identity provider‘a yönlendirilir. Consent işleminden sonra authorization code ve id token ile redirect uri‘ye tekrar yönlendirilmektedir. Sonrasındaysa token endpoint’ine authorization code verilerek access token ve başka bir id token alınır. Bu id token öncekiyle karşılaştırılarak doğrulanmaktadır. Client uygulaması scope kapsamında profile bilgisi belirttiğinden access token ile userinfo endpoint’ine giderek gerekli claim bilgilerini elde eder.