Learn about OAuth2, OpenID Connect, SAML, and Kerberos: Authentication and Authorization Methods in Modern Apps

Tram Ho

1. Introduction to OAuth2

OAuth2 (Open Authorization 2) is an extensible authentication and authorization protocol designed to provide access to user resources from third-party applications without sharing passwords. OAuth2 acts as an interface between the client, the user (resource owner) and the resource server.

The main purpose of OAuth2 is to ensure the safety and security of users when they share personal information and resources on their platform with other applications. For example, a user can grant application A permission to access their friends list on social network B without providing their login information to application A.

OAuth2 also simplifies authentication and authorization for applications by providing a common protocol, making it easier to integrate services and applications.

In this article, we will learn about the main components in OAuth2 and how they interact with each other to achieve the purpose of authentication and authorization.

2. Main components in OAuth2

2.1. Resource Owner

Resource Owner is an individual or organization that has control over access and use of protected resources. In the case of social networks, resource owners are users who have their personal information, friends lists, posts, and other data on their accounts.

The resource owner is responsible for granting clients access to their resources through OAuth2. This authorization process usually takes place when the user agrees to provide access to the client through an authentication and authorization interface.

Resource owners do not share their passwords directly with clients. Instead, they will issue an authorization code or access token to the client. The client then uses this code to access the owner’s resource without knowing their credentials.

In the next section, we will learn about another component in OAuth2, the Resource Server.

2.2. Resource Server

Resource Server is a system responsible for storing and managing protected resources. The resource server receives a request from the client to access the resource owner’s resources and responds to that request after successful authentication.

During this process, the resource server checks the access token provided by the client. If the access token is valid, the resource server will provide access to the requested resource according to the valid scope and time. The resource server can restrict access based on certain conditions, such as the scope of authorization granted to the client.

The resource server plays an important role in ensuring the information safety and security of the resource owner, by controlling access rights and providing information only when a valid access token is provided.

In the next section, we will learn about another component in OAuth2, which is Client.

2.3. Client

A client is a third-party application that wants to access the resource owner’s resources through the resource server. The client can be a web, mobile, desktop application, or a service running on a server.

To access the resource, the client needs to be authorized by the resource owner through OAuth2. When authorized, the client receives an access token or authorization code from the authorization server. This code will be used to access the resource from the resource server without knowing the resource owner’s credentials.

The client needs to register with the authorization server to receive information necessary for the authentication and authorization process, including information such as:

  • Client ID: A unique identifier given to the client when registering with the authorization server
  • Client secret: A secret string used to authenticate the client with the authorization server
  • Redirect URI: Is the address where the authorization server will send the authentication code or access token after the resource owner agrees to grant permission.

In the next chapter, we will learn about the final component in OAuth2, which is the Authorization Server.

2.4. Authorization Server

Authorization Server is a system responsible for authenticating resource owners and granting access tokens to clients. The Authorization server acts as an intermediary between the client, the resource owner, and the resource server.

When the client requests access to the resource owner’s resources, it is redirected to the authorization server. This server will authenticate the identity of the resource owner and ask them to agree to grant access to the resource to the client. After the resource owner agrees, the authorization server will issue an authorization code or access token to the client.

The client will use this authentication code or access token to access resources from the resource server. If the client receives an authentication token, it will have to exchange this token for an access token by sending a request to the authorization server with the authentication token, client ID, client secret, and redirect URI.

The Authorization server plays an important role in protecting the resource owner’s information and ensuring the authorization process takes place securely.

With an understanding of the key components in OAuth2, we’ll continue to explore the OAuth2 authentication and authorization flows in the next chapter.

3. Authentication flows in OAuth2

3.1. Authorization Code Flow

Authorization Code Flow is a popular authentication flow in OAuth2, suitable for clients such as web or desktop applications. This flow uses an authorization code as an intermediary to obtain the access token from the authorization server.

Here are the main steps of Authorization Code Flow:

  1. Authorization request: The client will redirect the user to the authorization server, with the following information:
    • Client ID
    • Redirect URI
    • Scope (authorized scope)
    • State (state, optional but recommended for increased security)
  2. Authentication and Authorization: The Authorization server will authenticate the identity of the resource owner and ask them to agree to grant resource access rights to the Client.
  3. Grant authorization code: If the resource owner agrees to grant permission, the Authorization server will send an authorization code to the client through the registered Redirect URI.
  4. Request access token: Client will send request to exchange authorization code for access token to Authorization server. This requirement should include:
    • Authorization code
    • Client ID
    • Client secret
    • Redirect URI
  5. Grant access token: If the request is valid, the Authorization server will issue the access token and refresh token (if supported) to the client.
  6. Resource access: The client will use the access token to access the resource owner’s resources from the resource server.

Authorization Code Flow helps protect the resource owner’s credentials and ensures that the access token is not exposed during transmission between the client and the authorization server. However, this flow requires the client to have a high level of security, ensuring that the client secret is not leaked.

In addition, using a refresh token allows the client to obtain a new access token without the user having to re-authorize. This creates a better user experience and reduces the need for authentication.

After understanding how Authorization Code Flow works, we will continue to learn about another authentication flow in OAuth2, which is Implicit Flow.

3.2. Implicit Flow

Implicit Flow is an authentication flow in OAuth2 designed for non-secure clients, such as JavaScript applications running in a browser. In this flow, the authorization server issues the access token directly to the client without going through an authorization code.

Here are the main steps of Implicit Flow:

  1. Authorization request: The client will redirect the user to the authorization server, with the following information:
    • Client ID
    • Redirect URI
    • Scope (authorized scope)
    • State (state, optional but recommended for increased security)
    • Response type: “token” (to indicate that the client wants to use Implicit Flow)
  2. Authentication and Authorization: The Authorization server will verify the identity of the resource owner and ask them to agree to grant access to the resource to the client.
  3. Grant access token: If the resource owner agrees to grant permission, the authorization server will send the access token to the client through the registered Redirect URI. It will be appended to the URL as a query or fragment parameter.
  4. Resource access: The client will use the access token to access the resource owner’s resources from the resource server.

Implicit Flow has the advantage of being simpler than Authorization Code Flow, but with less security. Access tokens can be exposed via the URL or temporarily stored in the browser. Therefore, this flow should only be used for clients that cannot use the client secret or authorization code.

However, it should be noted that Implicit Flow is being used less and less due to security limitations. Instead, many clients that do not have high security capabilities have switched to using PKCE (Proof Key for Code Exchange – discussed later), an additional method to Authorization Code Flow that enhances security for users. clients cannot use the client secret or authorization code.

Thus, we have learned about Implicit Flow, one of the authentication flows of OAuth2. Next, we will learn about another authentication flow in OAuth2, the Resource Owner Password Credentials Flow.

3.3. Resource Owner Password Credentials Flow

Resource Owner Password Credentials Flow is an authentication flow in OAuth2 that allows the client to use the resource owner’s credentials (username and password) to obtain an access token from the authorization server. This flow is suitable for applications that are trusted and already trusted by the resource owner, such as internal applications developed by the organization itself.

Here are the main steps of Resource Owner Password Credentials Flow:

  1. Collect login information: the client will ask the user to enter login information, including username and password.
  2. Request access token: the client will send a request to get the access token to the authorization server, along with the following information:
    • Client ID
    • Client secret (if any)
    • Grant type: “password” (to indicate that the client wants to use the Resource Owner Password Credentials Flow)
    • Username and password of resource owner
  3. Grant access token: If the credentials are valid, the authorization server will issue an access token and refresh token (if supported) to the client.
  4. Resource access: the client will use the access token to access the resource owner’s resources from the resource server.

Resource Owner Password Credentials Flow should not be used for untrusted clients, as collecting user credentials can present a security risk. However, in some specific cases, this flow can meet the needs of the organization and the users (For example, internal applications developed by the organization itself).

Next, we will learn about the final authentication flow in OAuth2, which is the Client Credentials Flow.

3.4. Client Credentials Flow

Client Credentials Flow is an authentication flow in OAuth2 dedicated to accessing resources that are not related to the end user (resource owner). In this flow, the client authenticates with the authorization server using its own credentials (client ID and client secret) to obtain the access token. This flow is often used in server-to-server applications, where the client needs to access the resource without the end user having to authorize it.

Here are the main steps of Client Credentials Flow:

  1. Request access token: the client will send a request to get the access token to the authorization server, along with the following information:
    • Client ID
    • Client secret
    • Grant type: “client_credentials” (to specify that the client wants to use Client Credentials Flow)
    • Scope (authorization scope, optional)
  2. Grant access token: If the client’s credentials are valid, the authorization server will issue the access token to the client.
  3. Resource access: The client will use the access token to access non-end-user related resources from the resource server.

Client Credentials Flow has the advantage of being simple and efficient for accessing non-end-user resources, which simplifies authentication and authorization for server-to-server applications.

Next, we’ll learn about some of the extension flows designed in OAuth2 to meet special needs and enhance security.

3.5. Extension Flows

In addition to the main OAuth2 authentication flows, there are several extended flows designed to meet special needs and enhance security. In this section, we will learn about some popular Extension Flows.

3.5.1. Proof Key for Code Exchange (PKCE)

PKCE (Proof Key for Code Exchange) is a new security method introduced by OAuth 2.0 to enhance the security of Authorization Code Flow. PKCE is designed to prevent security attacks that rely on an authorization code to obtain an access token from the Authorization Server.

The problem here is, if the client fails to secure the client secret, the authorization code can be stolen and used to obtain the access token by spoofing the client. This may result in the disclosure of user information or important data.

PKCE solves this problem by requiring the client to generate code challenge and code verifier before sending an authentication request. The code challenge is calculated based on the code verifier according to a predefined algorithm and sent to the Authorization Server along with the authentication request. The Authorization Server will check the code challenge against the authorization code and return the access token only if they match.

With PKCE, even if the authorization code is stolen, the hacker still cannot get the access token without the corresponding code challenge. Therefore, PKCE helps improve the security of Authorization Code Flow for applications that cannot guarantee client secrets, such as mobile applications or public applications.

Here are the main steps of Proof Key for Code Exchange (PKCE):

  1. Generate code challenge: Before sending an authorization request to the authorization server, the client generates a code challenge using a hash function on a random code verifier. This native code is stored on the client and is not sent to the authorization server.
  2. Authorization request: The client will redirect the user to the authorization server, with the following information:
    • Client ID
    • Redirect URI
    • Scope (authorized scope)
    • State (state, optional but recommended for increased security)
    • Response type: “code” (to indicate that the client wants to use Authorization Code Flow)
    • Code challenge method (the method used to create the code challenge, usually S256).
  3. Authentication and Authorization: The Authorization server will verify the identity of the resource owner and ask them to agree to grant access to the resource to the client.
  4. Grant authorization code: If the resource owner agrees to grant permission, the authorization server will send the authorization code to the client through the registered Redirect URI.
  5. Exchange authorization code: The client will use the authorization code to request the access token from the authorization server through a special request. This request will include both the original code and the challenge code generated in step 1.
  6. Code challenge validation: The Authorization server checks the validity of the code challenge by comparing it with the original code stored on the client. If the two codes match, the authorization server issues an access token to the client.

Through the use of PKCE, public applications can enhance security when using Authorization Code flows, prevent application spoofing attacks, and protect user privacy.

3.5.2. Device Flow

Device Flow is an OAuth2 authentication method specifically designed for devices without a keyboard or display, such as smart TVs, IoT devices, or virtual servers. In this case, authentication via another device (such as a smartphone) is required to perform the authentication process.

The working mechanism of Device Flow is quite simple. When a device needs to authenticate, it generates a device code and a verification URI that is displayed on the screen or transmitted to another device by some means. The user will access the authentication URL from an authenticated device (like a smartphone) and enter the device code to authenticate. Upon successful authentication, the Authorization Server will provide the device with an access token.

Device Flow is designed to address the security issue of authenticating devices without a keyboard or display. By requiring users to authenticate through another device, Device Flow reduces the risk of external attacks and enhances the security of IoT applications and devices.

The main steps in Device Flow:

  1. Request device code (device_code): The device sends a request to the Authorization Server to get the device code (device_code), user authentication code (user_code), and authentication path (verification_uri).
  2. Show authentication information: The device will show the user authentication code (user_code) and authentication path (verification_uri) to the user. The user enters the user authentication code (user_code) at the verification path (verification_uri) on another input-capable device, such as a smartphone.
  3. Authentication and Authorization User: The user logs into his account at the authentication path (verification_uri) on another device and authorizes the non-convenient input device to access the requested resources.
  4. Check Authentication Status: While the user is authenticating and authorizing, the device will continuously send requests to the Authorization Server to check the authentication and authorization status, using the device code (device_code) received. in step 1.
  5. Get access token (access_token): When the user completes the authentication and authorization process, the Authorization Server sends an access token (access_token) to the device on the next request to check the authentication status. . The device can use this access_token to access authorized resources.

Thanks to Device Flow, devices that are not convenient for input can authenticate and get access to authorized resources without the user having to enter credentials directly on the device.

Thus, we have learned about the main and extended authentication flows in OAuth2. Next, we’ll learn about OpenID Connect, an authentication standard built on top of OAuth2, and compare it to OAuth2.

4. OpenID Connect

4.1. About OpenID Connect

OpenID Connect (OIDC) is an authentication standard developed by the OpenID Foundation, based on OAuth2. OIDC is a combination of OAuth2 and several extensions, to provide a simple and secure user authentication solution for web, mobile and API applications.

The main purpose of OIDC is to help clients determine the user’s identity through an authentication server that the user trusts. This allows users to use existing accounts (eg, Google, Facebook accounts) to sign in to various applications without creating separate accounts for each application. This process is called Single Sign-On (SSO).

During authentication, OIDC provides information about the user in the form of a JSON Web Token (JWT) called the ID token. The token ID contains information such as the user’s identity, the token’s expiration time, and other information requested by the client. JWT is a standard token format that is easy to decipher and verify its validity.

OIDC works on top of OAuth2 authentication flows, such as Authorization Code Flow, Implicit Flow, and PKCE. However, while OAuth2 only provides access tokens to access user resources, OIDC also provides ID tokens to identify users.

The use of OIDC helps to reduce the security risks associated with handling user passwords, reduces the work of application developers in building and maintaining authentication systems, and increases user experience where they don’t need to remember multiple passwords for different applications.

Next, we will learn about how OpenID Connect works and the difference between OAuth2 and OpenID Connect.

4.2. How OpenID Connect works

OpenID Connect works on the OAuth2 platform, incorporating a number of extensions to provide user authentication functionality. Here’s how OIDC works:

  1. Authentication Required: When the user wants to log in to the client, the application redirects the user to the authorization server (usually an OpenID Provider, e.g. Google, Facebook). This request will contain information about the client, the request scopes, and some other information such as the desired authentication mode.
  2. User authentication: The Authorization server will check the user’s identity, either through logging in with an existing account or verifying through another method. After successful authentication, the user will provide consent for sharing personal information and access to resources with the client.
  3. Returns authentication code and token ID: After the user agrees, the authorization server returns an authorization code and ID token (in the form of JWT) to the client. The authentication code will be used in exchange for the access token, while the ID token contains information about the user’s identity.
  4. Change the authentication code into an access token and get user information: the client will send the authentication code to the authorization server in exchange for the access token. The client can then use this access token to access the user’s resources from the resource server. The application can also decrypt the ID token to obtain user information, such as identity, name, email address, profile picture, and other information upon request.
  5. Maintain login sessions and refresh tokens: Access tokens have an expiration date, so a client can request a refresh token from the authorization server to refresh the access token without the user having to sign in again. Refresh tokens typically have a longer duration than access tokens, allowing an application to maintain a user’s login session for a longer period of time.

So, we learned about how OpenID Connect works, a user authentication protocol based on OAuth2. Next, we will learn about SAML, Kerberos, and compare them with OAuth2 and OpenID Connect.

4.3. Difference between OAuth2 and OpenID Connect

Although OpenID Connect (OIDC) is built on top of OAuth2, the two protocols have different purposes and functions. Here are some key differences between OAuth2 and OIDC:

  1. Purpose
    • OAuth2: The OAuth2 protocol is primarily intended for authorization, allowing clients to access user resources without knowing their password. OAuth2 does not define a standard way to authenticate users.
    • OpenID Connect: OIDC is designed for user authentication (authentication), i.e. identifying the identity of the user accessing the application. OIDC builds on top of OAuth2 and extends its features to support user authentication.
  2. ID Token
    • OAuth2: The OAuth2 protocol does not provide token IDs. Instead, it uses an access token to authorize resource access.
    • OpenID Connect: OIDC uses an ID token (in the form of a JWT) to represent information about a user’s identity. The ID token is returned from the authorization server after the user agrees to share personal information and access to resources with the client.
  3. Scopes
    • OAuth2: Scopes in OAuth2 are used to request access to specific resources from users.
    • OpenID Connect: OIDC uses some special scopes, such as “openid”, “profile”, “email”, and “address”, to request user-specific information from the authorization server.

In summary, OAuth2 and OpenID Connect are both protocols related to user access and information, but they fulfill different needs. OAuth2 focuses on authorizing resource access, while OpenID Connect extends OAuth2 to support user identity authentication.

5. SAML

5.1. Introduction to SAML

SAML (Security Assertion Markup Language) is a protocol-based XML standard developed by OASIS (Organization for the Advancement of Structured Information Standards) for the exchange of authentication and authorization information between parties. SAML simplifies the login process for users as they access a variety of applications and web services.

SAML is commonly used in Single Sign-On (SSO) solutions, allowing users to sign in once and use that access to access many different applications without having to sign in again. SAML reduces user login difficulty and time, while increasing security and reducing the risks associated with managing multiple accounts and passwords.

The main structure of SAML consists of two components: Identity Provider (IdP) and Service Provider (SP). Identity Provider is the place that authenticates the user’s identity and provides authentication information to the Service Provider. Service Provider is the application or service that the user wants to access, which requires authentication from the Identity Provider to ensure the user has valid access.

Next, we will learn about how SAML works.

5.2. Cách thức hoạt động của SAML

SAML hoạt động dựa trên việc trao đổi các thông điệp XML giữa Identity Provider (IdP) và Service Provider (SP) để xác thực người dùng và truyền dữ liệu ủy quyền. Dưới đây là các bước chính trong quá trình hoạt động của SAML:

  1. Yêu cầu truy cập: Khi người dùng truy cập vào một ứng dụng hoặc dịch vụ (SP), họ sẽ được chuyển hướng đến IdP để xác thực danh tính.
  2. Xác thực danh tính: IdP sẽ kiểm tra danh tính của người dùng thông qua tài khoản và mật khẩu, xác nhận hai yếu tố hoặc các phương thức xác thực khác. Nếu xác thực thành công, IdP sẽ tạo ra một thông điệp SAML Assertion chứa thông tin xác thực và ủy quyền của người dùng.
  3. Truyền thông điệp SAML Assertion: IdP sẽ gửi thông điệp SAML Assertion đến SP thông qua trình duyệt của người dùng. Thông điệp này sẽ được ký bằng chữ ký số của IdP để đảm bảo tính bảo mật và toàn vẹn của dữ liệu.
  4. Xử lý SAML Assertion: SP sẽ kiểm tra chữ ký số của thông điệp SAML Assertion để đảm bảo rằng nó đến từ IdP đáng tin cậy. Sau đó, SP sẽ trích xuất thông tin xác thực và ủy quyền từ SAML Assertion để cấp quyền truy cập cho người dùng.
  5. Cấp quyền truy cập: Người dùng sẽ được cấp quyền truy cập vào ứng dụng hoặc dịch vụ (SP) dựa trên thông tin xác thực và ủy quyền từ SAML Assertion.

Quá trình hoạt động của SAML đảm bảo tính bảo mật, toàn vẹn dữ liệu và đơn giản hóa quá trình đăng nhập cho người dùng. Tiếp theo, chúng ta sẽ tìm hiểu về giao thức Kerberos và so sánh nó với các giao thức xác thực khác như OAuth2, OpenID Connect và SAML.

5.3. Ứng dụng của SAML trong Single Sign-On (SSO)

SAML được thiết kế chủ yếu để hỗ trợ Single Sign-On (SSO), một kỹ thuật cho phép người dùng đăng nhập một lần và truy cập nhiều ứng dụng hoặc dịch vụ mà không cần phải xác thực lại. SSO giúp đơn giản hóa quá trình xác thực, giảm thiểu khả năng quên mật khẩu và tăng cường bảo mật do không cần lưu trữ mật khẩu tại nhiều hệ thống. Dưới đây là cách SAML hỗ trợ SSO:

  1. Đăng nhập trung tâm: Người dùng chỉ cần đăng nhập một lần tại IdP. Sau đó, họ có thể truy cập nhiều ứng dụng hoặc dịch vụ (SP) mà không cần nhập lại tài khoản và mật khẩu.
  2. SAML Assertion: Khi người dùng truy cập vào một ứng dụng hoặc dịch vụ (SP) trong quá trình SSO, IdP sẽ tạo ra một thông điệp SAML Assertion chứa thông tin xác thực và ủy quyền của người dùng. Thông điệp này sẽ được truyền đến SP để cấp quyền truy cập.
  3. Chia sẻ thông tin giữa IdP và SP: SAML giúp truyền thông tin xác thực và ủy quyền giữa IdP và SP một cách bảo mật và hiệu quả. Điều này giúp đơn giản hóa việc quản lý danh tính người dùng và giảm thiểu khả năng bị rò rỉ thông tin.
  4. Bảo mật và toàn vẹn dữ liệu: SAML Assertion được ký bằng chữ ký số của IdP, đảm bảo tính bảo mật và toàn vẹn của dữ liệu trong quá trình truyền thông điệp giữa IdP và SP.

SAML là một giải pháp phổ biến trong việc triển khai SSO, giúp đơn giản hóa quá trình xác thực và cải thiện trải nghiệm người dùng. Tiếp theo, chúng ta sẽ tìm hiểu về giao thức Kerberos và so sánh nó với các giao thức xác thực khác như OAuth2, OpenID Connect và SAML.

6. Kerberos

6.1. Giới thiệu về Kerberos

Kerberos là một giao thức xác thực mạng được phát triển bởi MIT (Massachusetts Institute of Technology) vào những năm 1980. Giao thức này được thiết kế để cung cấp xác thực người dùng đáng tin cậy trong môi trường mạng không an toàn, bằng cách sử dụng công nghệ mã hóa để bảo mật thông tin xác thực. Kerberos đã trở thành một tiêu chuẩn xác thực trong môi trường mạng do sự hỗ trợ rộng rãi từ các nhà sản xuất phần mềm và phần cứng.

Kerberos hoạt động dựa trên mô hình “ủy quyền tập trung” với ba thành phần chính: Key Distribution Center (KDC), Client và Service. KDC chịu trách nhiệm quản lý và phân phối các “ticket” cho Client để truy cập Service. Client cần xác thực với KDC để nhận được ticket, sau đó sử dụng ticket này để xác thực với Service và nhận dịch vụ. Ticket được mã hóa bằng các khóa bí mật chung giữa KDC, Client và Service, đảm bảo tính bảo mật và toàn vẹn dữ liệu.

Mặc dù Kerberos không cung cấp các tính năng SSO hay ủy quyền như OAuth2 và SAML, nó vẫn là một giải pháp xác thực mạnh mẽ, phù hợp cho các môi trường mạng nội bộ hoặc doanh nghiệp. Trong phần tiếp theo, chúng ta sẽ tìm hiểu về cách thức hoạt động của Kerberos.

6.2. Cách thức hoạt động của Kerberos

Kerberos hoạt động dựa trên mô hình “ủy quyền tập trung” với ba thành phần chính: Key Distribution Center (KDC), Client và Service. Dưới đây là các bước trong quá trình xác thực của Kerberos:

  1. Xác thực Client với KDC:
  • Client gửi yêu cầu xác thực (Authentication Service Request – AS-REQ) đến KDC, bao gồm tên người dùng và tên dịch vụ mà người dùng muốn truy cập.
  • KDC kiểm tra thông tin xác thực của người dùng dựa trên cơ sở dữ liệu bên trong. Nếu thông tin xác thực hợp lệ, KDC sẽ tạo ra một “Ticket Granting Ticket” (TGT) và gửi lại cho Client dưới dạng một bản tin xác thực (Authentication Service Response – AS-REP). TGT được mã hóa bằng khóa bí mật chung giữa KDC và Client.
  1. Yêu cầu Ticket Granting Service (TGS) từ KDC:
  • Khi muốn truy cập vào một dịch vụ, Client sẽ gửi yêu cầu Ticket Granting Service (TGS-REQ) đến KDC, bao gồm TGT và tên dịch vụ cần truy cập.
  • KDC giải mã TGT bằng khóa bí mật của nó và kiểm tra tính hợp lệ của yêu cầu. Nếu hợp lệ, KDC sẽ tạo ra một “Service Ticket” và gửi lại cho Client dưới dạng một bản tin TGS (Ticket Granting Service Response – TGS-REP). Service Ticket được mã hóa bằng khóa bí mật chung giữa KDC và Service.
  1. Xác thực Client với Service
  • Client giải mã Service Ticket bằng khóa bí mật của nó và gửi yêu cầu dịch vụ (Service Request – S-REQ) đến Service, kèm theo Service Ticket.
  • Service giải mã Service Ticket bằng khóa bí mật của nó, kiểm tra tính hợp lệ của yêu cầu và thông tin Client. Nếu hợp lệ, Service sẽ xác nhận xác thực thành công và cung cấp dịch vụ cho Client.

Kerberos đảm bảo tính bảo mật và toàn vẹn dữ liệu trong quá trình xác thực bằng cách sử dụng mã hóa khóa bí mật chung giữa các thành phần. Tuy nhiên, Kerberos không hỗ trợ Single Sign-On (SSO) và ủy quyền như các giao thức OAuth2 và SAML.

6.3. Ứng dụng của Kerberos trong xác thực và ủy quyền

Kerberos là một giao thức xác thực được sử dụng rộng rãi trong các môi trường mạng doanh nghiệp và hệ thống phân tán. Dưới đây là một số ứng dụng phổ biến của Kerberos:

  1. Xác thực tập trung:

Kerberos cung cấp một mô hình xác thực tập trung, giúp giảm thiểu việc quản lý thông tin xác thực của người dùng trên nhiều hệ thống và dịch vụ khác nhau. KDC đóng vai trò trung tâm trong việc quản lý và kiểm soát quá trình xác thực, giúp nâng cao hiệu quả và đơn giản hóa quá trình quản lý.

  1. Bảo mật thông tin xác thực:

Kerberos sử dụng mã hóa khóa bí mật chung giữa các thành phần để bảo đảm tính bảo mật và toàn vẹn dữ liệu trong quá trình xác thực. Điều này giúp ngăn chặn các cuộc tấn công giả mạo và đảm bảo rằng thông tin xác thực của người dùng không bị đánh cắp hoặc thay đổi.

  1. Ứng dụng trong môi trường mạng doanh nghiệp:

Kerberos thường được sử dụng trong các môi trường mạng doanh nghiệp, đặc biệt là trong hệ thống Microsoft Active Directory. Kerberos giúp đơn giản hóa quá trình xác thực cho người dùng và dịch vụ trong môi trường mạng phức tạp và phân tán của doanh nghiệp.

  1. Hỗ trợ nhiều hệ điều hành và ứng dụng

Kerberos hỗ trợ nhiều hệ điều hành khác nhau, từ Windows, Linux đến macOS, cũng như nhiều ứng dụng phổ biến như Apache, OpenSSH và PostgreSQL. Điều này giúp đảm bảo tính tương thích và linh hoạt trong việc triển khai và tích hợp Kerberos vào các hệ thống và môi trường mạng đa dạng.

Tuy nhiên, cần lưu ý rằng Kerberos chủ yếu tập trung vào xác thực và không hỗ trợ Single Sign-On (SSO) hay ủy quyền như các giao thức OAuth2 và SAML. Trong một số trường hợp, Kerberos có thể được kết hợp với các giao thức khác như OpenID

7. So sánh OAuth2, OpenID Connect, SAML và Kerberos

7.1. Đặc điểm chung và khác biệt

Dưới đây là một số đặc điểm chung và khác biệt giữa các giao thức OAuth2, OpenID Connect, SAML và Kerberos:

  1. Đặc điểm chung
  • Cả OAuth2, OpenID Connect, SAML và Kerberos đều là các giao thức xác thực và ủy quyền được thiết kế để giải quyết các vấn đề bảo mật trong việc truy cập và sử dụng dữ liệu và dịch vụ trực tuyến.
  • Các giao thức này đều hỗ trợ xác thực người dùng và đảm bảo rằng chỉ những người dùng có quyền hạn mới có thể truy cập vào các tài nguyên và dịch vụ được bảo vệ.
  1. Khác biệt
  • Mục đích:
    • OAuth2 chủ yếu tập trung vào ủy quyền, giúp người dùng chia sẻ quyền truy cập vào tài nguyên của họ với các ứng dụng bên thứ ba mà không cần chia sẻ thông tin xác thực trực tiếp.
    • OpenID Connect được xây dựng trên nền tảng OAuth2 nhưng mở rộng để hỗ trợ xác thực người dùng thông qua cung cấp thông tin người dùng (ID Token).
    • SAML tập trung vào xác thực và ủy quyền dựa trên XML, đặc biệt là trong Single Sign-On (SSO) giữa các nhà cung cấp dịch vụ và nhà cung cấp danh tính.
    • Kerberos là một giao thức xác thực tập trung sử dụng mã hóa khóa bí mật để đảm bảo bảo mật trong quá trình xác thực.
  • Phương thức hoạt động:
    • OAuth2 và OpenID Connect sử dụng token để xác thực và ủy quyền, giúp giảm thiểu rủi ro thông tin xác thực bị đánh cắp.
    • SAML sử dụng các thông điệp XML được ký bằng chữ ký số để đảm bảo tính bảo mật và toàn vẹn của thông tin xác thực và ủy quyền.
    • Kerberos sử dụng mã hóa khóa bí mật chung giữa các thành phần để đảm bảo tính bảo mật và toàn vẹn dữ liệu trong quá trình xác thực.
  • Môi trường ứng dụng:
    • OAuth2 và OpenID Connect rất phổ biến trong các ứng dụng web và di động hiện đại, cho phép người dùng đăng nhập và chia sẻ quyền truy cập vào tài nguyên của họ với các ứng dụng bên thứ ba một cách an toàn và tiện lợi.
    • SAML thường được sử dụng trong các môi trường doanh nghiệp và giữa các tổ chức, đặc biệt trong các giải pháp Single Sign-On (SSO) giúp người dùng truy cập nhiều dịch vụ với một lần đăng nhập duy nhất.
    • Kerberos phổ biến trong các môi trường mạng doanh nghiệp, nhất là trong hệ thống Microsoft Active Directory, cung cấp xác thực tập trung cho người dùng và dịch vụ trong môi trường mạng phức tạp và phân tán của doanh nghiệp.

Như vậy, mỗi giao thức có những ưu điểm và điểm mạnh riêng, phù hợp với các mục đích và môi trường ứng dụng khác nhau. Trong khi OAuth2 và OpenID Connect phù hợp với các ứng dụng web và di động hiện đại, SAML tập trung vào giải pháp Single Sign-On trong môi trường doanh nghiệp, và Kerberos giúp đơn giản hóa quá trình xác thực tập trung trong mạng doanh nghiệp.

7.2. Ưu và nhược điểm của từng công nghệ

7.2.1. OAuth2

  1. Ưu điểm:
    • Linh hoạt và mở rộng: OAuth2 hỗ trợ nhiều luồng xác thực phù hợp với nhiều mục đích và ứng dụng khác nhau.
    • Phổ biến và dễ tích hợp: Nhiều dịch vụ lớn như Google, Facebook, và Twitter đều sử dụng OAuth2.
    • Bảo mật cao: OAuth2 cho phép người dùng chia sẻ quyền truy cập vào tài nguyên của họ mà không cần chia sẻ mật khẩu.
  2. Nhược điểm:
    • Phức tạp: OAuth2 có nhiều luồng xác thực và quy trình xác thực khá phức tạp.
    • Không xác định danh tính người dùng: OAuth2 chỉ xác nhận quyền truy cập, không xác định danh tính người dùng.

7.2.2. OpenID Connect

  1. Advantage
    • Xác định danh tính người dùng: OpenID Connect mở rộng OAuth2 để xác định danh tính người dùng.
    • Tương thích với OAuth2: OpenID Connect dựa trên OAuth2, giúp tích hợp dễ dàng vào các ứng dụng sử dụng OAuth2.
    • Hỗ trợ Single Sign-On: OpenID Connect hỗ trợ SSO, giúp người dùng đăng nhập vào nhiều dịch vụ với một lần đăng nhập duy nhất.
  2. Defect
    • Cũng khá phức tạp: OpenID Connect kế thừa độ phức tạp của OAuth2.

7.2.3. SAML

  1. Ưu điểm:
    • Đã được chứng minh trong các môi trường doanh nghiệp: SAML là một chuẩn xác thực phổ biến trong các môi trường doanh nghiệp và giữa các tổ chức.
    • Hỗ trợ Single Sign-On: SAML giúp người dùng truy cập nhiều dịch vụ với một lần đăng nhập duy nhất.
    • Bảo mật cao: SAML sử dụng kỹ thuật mã hóa và chữ ký số để đảm bảo tính bảo mật của thông tin xác thực.
  2. Nhược điểm:
    • Khó tích hợp: SAML có thể khó tích hợp vào các ứng dụng hiện đại, đặc biệt là ứng dụng di động.
    • XML-heavy: SAML sử dụng XML, có thể gây ra tốn kém về tài nguyên và khó tiếp cận đối với một số lập trình viên.

7.2.4. Kerberos

  1. Ưu điểm:
    • Bảo mật cao: Kerberos sử dụng mã hóa đối xứng và chứng từ (ticket) để đảm bảo tính bảo mật cho quá trình xác thực.
    • Hiệu năng tốt: Kerberos giảm thiểu số lượng truy vấn xác thực, giúp cải thiện hiệu năng hệ thống.
    • Đã được chứng minh: Kerberos đã được sử dụng rộng rãi trong các hệ thống mạng lớn, như mạng của MIT và Microsoft Active Directory.
  2. Nhược điểm:
    • Phụ thuộc vào thời gian: Kerberos đòi hỏi đồng bộ hóa thời gian giữa các thành phần hệ thống, điều này có thể gây khó khăn trong một số trường hợp.
    • Khó mở rộng: Kerberos khó mở rộng đối với các ứng dụng phân tán và đa tổ chức, đặc biệt là khi cần tương tác với các ứng dụng bên ngoài hệ thống.
    • Khó tích hợp: Kerberos có thể khó tích hợp với các công nghệ xác thực khác và đòi hỏi kiến thức chuyên sâu để triển khai thành công.

Sau khi đã nắm được ưu và nhược điểm của từng công nghệ, bạn có thể lựa chọn phương thức xác thực phù hợp với nhu cầu và ứng dụng của mình.

7.3. Lựa chọn phù hợp cho các tình huống khác nhau

Dựa trên ưu và nhược điểm của từng công nghệ, dưới đây là một số khuyến nghị cho việc lựa chọn phương thức xác thực phù hợp với các tình huống khác nhau:

  1. Ứng dụng di động và ứng dụng web hiện đại: Nếu bạn đang xây dựng ứng dụng di động, ứng dụng đơn trang (SPA) hoặc ứng dụng web hiện đại, việc sử dụng OAuth2 kết hợp với OpenID Connect là lựa chọn tốt nhất. Cả hai công nghệ này đều hỗ trợ JSON và RESTful API, phù hợp với xu hướng hiện tại của ứng dụng web và di động.
  2. Ứng dụng doanh nghiệp và hệ thống phân quyền: Nếu bạn đang xây dựng hệ thống cho một tổ chức lớn với nhiều ứng dụng và dịch vụ nội bộ, SAML có thể là lựa chọn phù hợp. SAML hỗ trợ Single Sign-On (SSO), giúp người dùng dễ dàng truy cập vào các dịch vụ khác nhau mà không cần phải đăng nhập nhiều lần. Tuy nhiên, nếu bạn muốn tích hợp với các ứng dụng bên ngoài, OAuth2 và OpenID Connect có thể là lựa chọn tốt hơn.
  3. Mạng nội bộ và hệ thống máy tính để bàn: Đối với các môi trường mạng nội bộ và hệ thống máy tính để bàn, Kerberos có thể là lựa chọn phù hợp. Kerberos được thiết kế để đáp ứng các yêu cầu về bảo mật và hiệu năng cao trong môi trường mạng nội bộ. Tuy nhiên, nếu bạn cần tương tác với các ứng dụng bên ngoài, việc sử dụng OAuth2 và OpenID Connect có thể là lựa chọn tốt hơn.
  4. Ứng dụng đa tổ chức và đám mây: Trong trường hợp bạn cần xây dựng ứng dụng đa tổ chức hoặc chạy trên môi trường đám mây, việc sử dụng OAuth2 và OpenID Connect sẽ mang lại nhiều lợi ích hơn. Cả hai công nghệ này đều hỗ trợ tốt việc xác thực và ủy quyền cho nhiều tổ chức và ứng dụng khác nhau, giúp đơn giản hóa quá trình quản lý truy cập và bảo mật cho các ứng dụng chạy trên đám mây. Nếu bạn muốn đảm bảo tương thích rộng rãi và dễ dàng tích hợp với các dịch vụ bên ngoài, OAuth2 và OpenID Connect là lựa chọn hợp lý.

Tóm lại, việc lựa chọn phương thức xác thực và ủy quyền phù hợp phụ thuộc vào nhiều yếu tố, bao gồm mục đích sử dụng, môi trường ứng dụng, và yêu cầu về bảo mật. OAuth2 và OpenID Connect phù hợp với các ứng dụng web, di động và đám mây hiện đại; SAML thích hợp cho các ứng dụng doanh nghiệp và hệ thống phân quyền; trong khi đó, Kerberos hoạt động tốt trong môi trường mạng nội bộ và hệ thống máy tính để bàn. Cân nhắc kỹ các yếu tố này sẽ giúp bạn đưa ra quyết định phù hợp cho hệ thống của mình.

8. Ứng dụng OAuth2 và OpenID Connect

8.1. OAuth2 và OpenID Connect trong ứng dụng client-to-server

Trong ứng dụng client-to-server, một ứng dụng client (thường là ứng dụng web hoặc di động) cần truy cập vào các tài nguyên được lưu trữ trên một máy chủ (resource server) thay mặt cho người dùng (resource owner). OAuth2 và OpenID Connect đóng vai trò quan trọng trong việc xác thực và ủy quyền giữa các thành phần này.

  1. Sử dụng OAuth2 trong ứng dụng client-to-server:
  • Trong trường hợp này, ứng dụng client sẽ sử dụng luồng xác thực phù hợp (như Authorization Code Flow hoặc Implicit Flow) để nhận access token từ Authorization Server.
  • Sau khi nhận được access token, ứng dụng client sẽ sử dụng nó để gọi các API được bảo vệ trên resource server thay mặt cho người dùng.
  • OAuth2 giúp đảm bảo rằng ứng dụng client chỉ có quyền truy cập vào những tài nguyên mà người dùng đã cấp quyền.
  1. Sử dụng OpenID Connect trong ứng dụng client-to-server:
  • OpenID Connect được xây dựng dựa trên OAuth2 và bổ sung thêm các tính năng xác thực người dùng. Khi ứng dụng client cần xác thực người dùng, nó sẽ chuyển hướng người dùng đến Authorization Server và yêu cầu một ID token.
  • ID token được trả về cho ứng dụng client dưới dạng một chuỗi JWT (JSON Web Token), chứa thông tin về người dùng và các thông tin bổ sung khác.
  • Ứng dụng client có thể kiểm tra ID token để xác thực người dùng và lưu trữ thông tin người dùng một cách an toàn.

Bằng cách kết hợp OAuth2 và OpenID Connect, ứng dụng client-to-server có thể đảm bảo an toàn và bảo mật trong việc truy cập vào các tài nguyên của người dùng, đồng thời xác thực người dùng một cách hiệu quả và đáng tin cậy.

8.2. OAuth2 và OpenID Connect trong ứng dụng server-to-server

Trong mô hình ứng dụng server-to-server, các máy chủ (server) trao đổi thông tin với nhau mà không cần sự tham gia của người dùng. OAuth2 và OpenID Connect cũng có thể được sử dụng trong những tình huống này để đảm bảo bảo mật và ủy quyền giữa các máy chủ.

  1. Sử dụng OAuth2 trong ứng dụng server-to-server:
  • Trong trường hợp này, máy chủ A (client) sẽ sử dụng luồng xác thực Client Credentials Flow để nhận access token từ Authorization Server. Lưu ý rằng trong tình huống này, không cần người dùng (resource owner) tham gia.
  • Sau khi nhận được access token, máy chủ A sẽ sử dụng nó để gọi các API được bảo vệ trên máy chủ B (resource server).
  • OAuth2 giúp đảm bảo rằng chỉ những máy chủ được ủy quyền mới có quyền truy cập vào các tài nguyên trên resource server.
  1. Sử dụng OpenID Connect trong ứng dụng server-to-server:
  • Trong một số trường hợp, máy chủ A có thể cần xác thực danh tính của một người dùng hoặc một dịch vụ khác khi giao tiếp với máy chủ B. OpenID Connect có thể được sử dụng để đạt được mục đích này.
  • Máy chủ A sẽ gửi yêu cầu xác thực đến Authorization Server và nhận về một ID token, chứa thông tin về người dùng hoặc dịch vụ được xác thực.
  • Máy chủ A sau đó có thể gửi ID token này đến máy chủ B trong các yêu cầu API, cho phép máy chủ B xác thực danh tính của người dùng hoặc dịch vụ liên quan.

Khi kết hợp OAuth2 và OpenID Connect trong ứng dụng server-to-server, các máy chủ có thể trao đổi thông tin một cách an toàn và bảo mật, đồng thời đảm bảo xác thực danh tính của người dùng hoặc dịch vụ khi cần thiết.

9. Kết luận

Qua bài viết này, chúng ta đã tìm hiểu về OAuth2, OpenID Connect, SAML và Kerberos – những công nghệ quan trọng trong lĩnh vực xác thực và ủy quyền. Chúng ta đã đi qua từng công nghệ, cách hoạt động, ưu nhược điểm, và các tình huống thích hợp để sử dụng từng công nghệ. Đặc biệt, chúng ta đã tìm hiểu về cách ứng dụng OAuth2 và OpenID Connect trong mô hình ứng dụng client-to-server và server-to-server.

Hiểu rõ về các công nghệ này sẽ giúp chúng ta xây dựng các ứng dụng an toàn hơn và đáp ứng được yêu cầu về bảo mật thông tin trong thời đại số hóa ngày nay. Tuy nhiên, đây chỉ là khởi đầu, và để có thể áp dụng thành thạo các công nghệ này, chúng ta cần nghiên cứu sâu hơn và thực hành nhiều hơn.

10. Tài liệu tham khảo

  1. Hardt, D. (2012). The OAuth 2.0 Authorization Framework. IETF. doi:10.17487/RFC6749. [Online]. Available: https://tools.ietf.org/html/rfc6749
  2. Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2014). OpenID Connect Core 1.0. OpenID Foundation. [Online]. Available: https://openid.net/specs/openid-connect-core-1_0.html
  3. Cantor, S., Kemp, J., Philpott, R., & Maler, E. (2005). Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS. [Online]. Available: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
  4. Neuman, C., Yu, T., Hartman, S., & Raeburn, K. (2005). The Kerberos Network Authentication Service (V5). IETF. doi:10.17487/RFC4120. [Online]. Available: https://tools.ietf.org/html/rfc4120
  5. Jones, M. (2012). JSON Web Token (JWT). IETF. doi:10.17487/RFC7519. [Online]. Available: https://tools.ietf.org/html/rfc7519
  6. ORY Hydra – OAuth2 Server and OpenID Certified™ OpenID Connect Provider. [Online]. Available: https://www.ory.sh/hydra
Share the news now

Source : Viblo