OAuth2 Authorization Code Grant

Giriş

Authorization Code Grant ve PKCE

Açıklaması şöyle

PKCE is required for all OAuth clients using the authorization code flow

Verifier ve challenge şöyle. Yani challenge bir hash değeri

verifier = "random string code"

challenge = hash(verifier)

Açıklaması şöyle. Burada işi authorization server yapıyor gibi anlatılıyor

PKCE (pronounced “pixy”) stands for “Proof Key for Code Exchange.” It is a security mechanism that is used to protect authorization code grants when used with OAuth 2.0 and OpenID Connect.

When an application wants to access a user’s resources on a resource server (such as an API), the application must first obtain an authorization code from the authorization server. This authorization code can then be exchanged for an access token, which allows the application to access the user’s resources.

However, this process can be vulnerable to attacks if the authorization code is intercepted by an attacker. PKCE was introduced to protect against this type of attack by requiring the application to include additional information, called a “code verifier,” when requesting the authorization code. The authorization server includes this code verifier when issuing the authorization code, and the application must provide it again when exchanging the authorization code for an access token. This ensures that the application is the one that initiated the request, rather than an attacker who may have intercepted the authorization code.

PKCE is particularly important when an application is using the authorization code grant type in a native application, as it is more vulnerable to code interception attacks.

PKCE will be mandatory with the authorization code flow in OAUTH 2.1

Bir başka açıklaması şöyle. Burada işi client yapıyor gibi anlatılıyor

- When the user is redirected to the login page, the client application generates the verifier and the challenge.

- The challenge is sent to the Authorization Server along with user credentials for authentication request.

After successful authentication and getting the Authorization Code, the client makes the request to get the access token, and instead of sending the client credentials along with the request the client sends the verifier to the Authorization Server.

The Authorization Server that already has the challenge now can validate if the verifier is indeed the same as the challenge by using the hash function matches.

Authorization Code Grant Nedir?

Açıklaması şöyle.

The flow works this way, you visit a third-party site and it redirects you to the authorization server's login page, and you log in there, the authorization server redirects you back to the site issuing the authorization code. The client application then uses the authorization code to get the access token for accessing your protected resources on the resource server.

Akış şöyle. 

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Şeklen şöyle

Bir başka şekil burada.

Authorization Request

Örnek

Şöyledir

/oauth/authorize 
   ?client_id=a17c21ed 
   &response_type=code 
   &state=5ca75bd30 
   &redirect_uri=https://example.com/cb 
   &scope=photos

Açıklaması şöyle

Once the authorization server receives the request it should perform the following steps:
1. Verify user identity for example against access token. The request contains users' consent so it must be secured with user identity.

2. Validate request parameters:
  - client_id should be registered to authorization server with exact redirect_uri
  - response_type specifies which OAuth 2.0 flow is requested; for authorization code flow it should be equal to code
  - state contains a random string generated on the client to be verified against the one returned in response; they should be equal
  - scope contains a list of scopes requested by the client

3. Generate authorization code: This should be a random string secure enough to not be guessed.
4. Store in DB request data: The authorization code and user data (probably from token) to use them while token issuance

Authorization Response

Örnek

Şöyledir.  Burada authorization code cevabını alıyoruz

https://example.com/cb
  ?state=txcSDMn3Q5bZ-w32
  &code=EVOcNHq7TBVaxVw

Açıklaması şöyle

The authorization response is a redirect back to the client to the redirect_uri specified in the authorization request. The code parameter contains the authorization code and the state originally passed by the client.

Açıklaması şöyle

After successful user authentication, the Authorization Server sends the client Authorization Code. The Authorization Code can be used only once by the client to get access token. It doesn’t matter whether the request by the client was successful or not, once the Authorization Code is consumed by the Authorization Server it cannot be used anymore.

Token Exchange Request

Şöyledir. Burada backend de de çalışan uygulamamız authorization code + client credentials gönderiyor

/token
  ?code=EVOcNHq7TBVaxVw
  &grant_type=code
  &redirect_uri=https://example.com/cb
  &client_id=a17c21ed
  &client_secret=ZGVmMjMz

Açıklaması şöyle

The /token endpoint receives parameters needed to issue access token:
- code contains authorization code generated as a result of authorization request; it's a key by which authorization server should look for data in DB.
- grant_type specifies which way the server should issue access tokens; code means the token should be issued based on the authorization code.
- client_id and client_secret (or code_verifier in case of using PKCE) are needed to authorize the request since just authorization code validation is not enough because it might be intercepted.
- Get data from DB by the authorization code, the most important of which are user id and scopes requested. Therefore, the access token issued should represent the users and should be limited to scopes they confirmed giving consent.
- Issue tokens (most probably your would like to issue refresh token alongside with access one)

Token Exchange Response 

Şöyledir. Burada access token alıyoruz

{ 
  "token_type": "Bearer", 
  "expires_in": 86400, 
  "access_token": "sjmHG1EywNbSDAelt",
  "refresh_token": "Qb6kKM4BWPIwq" 
}

Delegated Authorization vs Federated Authentication

Authorization Code Grant akışına "Delegated Authorization" denilir. Çünkü sadece bir kaynağa (resource) belli bir erişim hakkı veriyoruz. "OpenID Connect" ile ayrıldıkları nokta burası, çünkü "OpenID Connect"  "Delegated Authorization" yerine "Federated Authentication" kullanıyor. Açıklaması şöyle. Yani authorization (yetkilendirme) yerine, authentication (doğrulama) yapılıyor

Note that Federated Authentication is different from Delegated Authorization.

Federated Authentication allows you to login to a site using your facebook or google account.

Delegated Authorization is the ability of an external app to access resources. This use case would be for example Spotify trying to access your google contacts list to import it into Spotify.

OAuth 2.0 was designed primarily for delegated authorization, OpenId Connect is the few additional steps added over OAuth 2.0 to extend OAuth 2.0 for Federated Authentication.

Fark aslında çok basit bir şeyden kaynaklanıyor. Open ID access token'a ilave olarak bir de id_token kullanıyor. Açıklaması şöyle

1. it introduces a completely new token (id_token) with radically different semantics than the OAuth 2.0 access_token and a standardized format that is understood by the Client as opposed to the access_token which is opaque to the Client

2. it "twists" the role of the Client, now becoming the "audience" (or: intended recipient) of a token (i.e. the id_token) whilst the audience of the access_token is still a remote entity (aka. Resource Server) and the Client is only the "presenter" of the latter

The 2nd item is the primary source of confusion between OAuth 2.0 and OpenID Connect.