OAuth 2.0 và OpenID Connect (OIDC)

1. Tổng quan

A. Định nghĩa

OAuth 2.0 là khung ủy quyền (Authorization framework, RFC 6749) nhằm ủy thác quyền truy cập trong phạm vi giới hạn (scope) mà không làm lộ mật khẩu của chủ sở hữu tài nguyên (người dùng) cho ứng dụng bên thứ ba. OpenID Connect (OIDC) là giao thức xác thực (Authentication) đặt thêm lên OAuth 2.0 một tầng chứng minh danh tính đã được chuẩn hóa gọi là ID Token, để xác nhận "người dùng này là ai".

Hai tiêu chuẩn thường được gọi gộp làm một nhưng giải quyết các vấn đề khác nhau. OAuth 2.0 được thiết kế để trả lời câu hỏi về quyền hạn (authorization) "ứng dụng này có thể làm gì thay mặt người dùng", và vốn không nhằm chứng minh danh tính người dùng. Trên thực tế, các dịch vụ web thời kỳ đầu đã dùng mẹo (pseudo-authentication) chỉ dựa vào việc cấp access token của OAuth thành công để coi là đăng nhập thành công, và gặp phải các lỗ hổng tái sử dụng token · nhầm lẫn đối tượng nhận (audience confusion). Để giải quyết tận gốc các vấn đề này, OpenID Foundation đã chuẩn hóa OIDC vào năm 2014, tách bạch rõ ai đã đăng nhập (authentication) và được truy cập vào cái gì (authorization), đồng thời chuẩn hóa vế trước thành ID Token dạng JWT có thể kiểm chứng việc giả mạo · sửa đổi (Duende Software).

B. Bối cảnh ra đời và sự cần thiết

Trước đây, việc liên kết giữa các dịch vụ web phổ biến theo cách người dùng nhập trực tiếp ID · mật khẩu của mình vào dịch vụ bên kia (chia sẻ mật khẩu, password anti-pattern). Cách này khiến mật khẩu bị lưu rải rác ở nhiều dịch vụ làm tăng nguy cơ rò rỉ, và người dùng không thể chỉ ủy thác một số quyền nhất định hay thu hồi về sau. OAuth giải quyết vấn đề này bằng cách để người dùng đăng nhập tại máy chủ ủy quyền mà họ tin cậy (ví dụ: Google, Kakao), rồi chỉ cấp cho ứng dụng client token có phạm vi giới hạn và có thể thu hồi. Khi bổ sung OIDC, đã có thể thực hiện SSO (Single Sign-On) — đăng nhập vào nhiều dịch vụ bằng một tài khoản — và liên kết danh tính chuẩn hóa trong môi trường microservice, ứng dụng di động, SPA (Single Page Application). Hiện nay, phần lớn đăng nhập mạng xã hội ("Đăng nhập bằng Google", "Đăng nhập bằng Kakao") và SSO doanh nghiệp (Okta, Azure AD, Keycloak v.v.) được hiện thực bằng tổ hợp hai tiêu chuẩn này.

2. Cấu trúc tổng thể và các chủ thể tham gia

flowchart LR
  RO[Resource Owner<br/>Người dùng] -->|Đăng nhập·đồng ý| AS[Authorization Server<br/>Máy chủ ủy quyền]
  AS -->|Authorization Code| C[Client<br/>Ứng dụng]
  C -->|Trao đổi Code| AS
  AS -->|Access Token + ID Token| C
  C -->|Xuất trình Access Token| RS[Resource Server<br/>Máy chủ API]
  RS -->|Phản hồi tài nguyên được bảo vệ| C

Hệ sinh thái OAuth/OIDC gồm bốn chủ thể chính, và phải hiểu chính xác vai trò cũng như ranh giới tin cậy của từng chủ thể thì mới thiết kế · kiểm toán được luồng ủy quyền.

Chủ sở hữu tài nguyên (Resource Owner): Là người dùng — chủ sở hữu thực sự của tài nguyên được bảo vệ (ảnh, hồ sơ, email v.v.). Đây là chủ thể đăng nhập trên màn hình của máy chủ ủy quyền và đồng ý (consent) "có cho phép ứng dụng này truy cập email của tôi không", và sự rõ ràng của giao diện đồng ý này là tuyến phòng thủ thực chất của toàn bộ mô hình tin cậy.
Client: Là ứng dụng muốn truy cập tài nguyên. Tùy theo có thể lưu giữ an toàn khóa bí mật của client hay không mà chia thành client bí mật (confidential, ứng dụng phía máy chủ) và client công khai (public, di động · SPA), và sự phân biệt này là tiêu chí cốt lõi để chọn loại grant sẽ được trình bày ở phần sau.
Máy chủ ủy quyền (Authorization Server): Là điểm trung tâm của sự tin cậy, xác thực người dùng, nhận sự đồng ý và cấp token. Khi hỗ trợ OIDC, nó còn được gọi là OpenID Provider (OP), và cung cấp chức năng khám phá (Discovery) công bố theo cách chuẩn hóa các endpoint · thuật toán hỗ trợ của mình qua đường dẫn /.well-known/openid-configuration.
Máy chủ tài nguyên (Resource Server): Là máy chủ nắm giữ API · dữ liệu được bảo vệ thực sự, chỉ phản hồi sau khi kiểm tra tính hợp lệ và scope của access token do client xuất trình.

Các loại token và thiết kế thời hạn sống (tham khảo)

Các token được xử lý trong hệ sinh thái OAuth/OIDC có bản chất khác nhau, và nếu nhầm lẫn thì toàn bộ thiết kế bảo mật sẽ lung lay. Access Token là "vé vào cửa" xuất trình cho máy chủ tài nguyên, định dạng không được chuẩn hóa nên có thể là chuỗi tùy ý không trong suốt (opaque token) hoặc JWT. ID Token bắt buộc phải là JWT và là giấy chứng nhận danh tính được thiết kế để client tự giải mã · kiểm chứng. Refresh Token tuyệt đối không được xuất trình cho máy chủ tài nguyên, là token dùng để cấp lại, chỉ được dùng khi yêu cầu máy chủ ủy quyền cấp access token mới.

Token	Đối tượng xuất trình	Định dạng	Thời hạn sống thông thường
Access Token	Máy chủ tài nguyên (API)	Chuỗi không trong suốt hoặc JWT	5 phút~1 giờ
ID Token	Client (chính ứng dụng)	JWT (bắt buộc)	Kiểm chứng một lần (không tái sử dụng)
Refresh Token	Máy chủ ủy quyền	Khuyến nghị chuỗi không trong suốt	Vài ngày~vài tháng (áp dụng xoay vòng)

Ví dụ, nếu một nền tảng thương mại đặt thời hạn access token là 30 phút và refresh token là 14 ngày, người dùng chỉ cần đăng nhập lại hai tuần một lần, nhưng ngay cả khi access token bị đánh cắp, thời gian kẻ tấn công có thể lạm dụng bị giới hạn tối đa 30 phút. Bản thân việc thiết kế tách biệt thời hạn sống của hai token như vậy trở thành luận điểm cốt lõi trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer) khi bàn về "cân bằng giữa tính tiện dụng và bảo mật".

3. Các loại cấp quyền (Grant) của OAuth 2.0

Grant ủy quyền là quy cách theo từng kịch bản về "client nhận token theo cách nào", và việc lựa chọn phụ thuộc vào mức độ tin cậy của client và việc có sự tham gia của người dùng hay không.

A. Authorization Code Grant (+ PKCE)

Là luồng an toàn và chuẩn mực nhất, được dùng cho ứng dụng máy chủ web và cả ứng dụng di động · SPA khi bổ sung PKCE (Proof Key for Code Exchange, RFC 7636).

sequenceDiagram
  participant U as Người dùng (trình duyệt)
  participant C as Client
  participant AS as Authorization Server
  U->>C: Yêu cầu đăng nhập
  C->>U: Chuyển hướng tới AS (+code_challenge)
  U->>AS: Đăng nhập·đồng ý
  AS->>U: Cấp Authorization Code (chuyển hướng)
  U->>C: Chuyển Code
  C->>AS: Trao đổi token bằng Code + code_verifier
  AS->>C: Access Token + ID Token(+Refresh Token)

Cốt lõi của luồng này là ngay cả khi mã ủy quyền (authorization code) bị lộ qua trình duyệt, việc trao đổi token thực tế được thực hiện qua giao tiếp kênh sau (back-channel) giữa client và máy chủ ủy quyền. Bản thân mã có thời gian sống ngắn (vài chục giây~vài phút) và chỉ dùng một lần nên giá trị lạm dụng thấp dù bị đánh cắp. Tuy nhiên, client công khai không thể lưu giữ an toàn khóa bí mật của client, nên bổ sung PKCE để ngăn tấn công chặn bắt mã ủy quyền (authorization code interception). PKCE yêu cầu client tạo một code_verifier ngẫu nhiên và đưa giá trị băm của nó là code_challenge vào yêu cầu ủy quyền, để tại thời điểm trao đổi token thực tế phải xuất trình kèm code_verifier gốc thì mới được cấp token. Nhờ vậy, dù kẻ tấn công chặn được URI chuyển hướng và đánh cắp mã, vì không biết bộ kiểm chứng tương ứng nên không thể đổi thành token.

B. Client Credentials Grant

Được dùng cho giao tiếp máy chủ-với-máy chủ (machine-to-machine) không có sự tham gia của người dùng. Client chỉ dùng client ID · secret của mình để trực tiếp yêu cầu token từ máy chủ ủy quyền, nhận quyền truy cập bằng danh tính của chính ứng dụng chứ không phải ủy thác của người dùng. Thường được dùng trong tác vụ batch, gọi API giữa các microservice backend, script quản trị v.v., và chỉ được dùng ở client bí mật (máy chủ có thể lưu giữ an toàn khóa bí mật).

C. Refresh Token Grant

Access token có thời gian hết hạn ngắn (vài phútvài chục phút) để giảm thiệt hại khi bị đánh cắp. Nếu mỗi lần đều yêu cầu người dùng đăng nhập lại thì tính tiện dụng giảm mạnh, vì vậy dùng refresh token được cấp cùng lúc ủy quyền ban đầu để cấp lại access token mới mà không cần người dùng tham gia. Refresh token có thời hạn dài hơn access token (vài ngàyvài tháng) và thiệt hại lớn khi bị đánh cắp, nên thông lệ bảo mật mới nhất là chỉ để ở kho lưu trữ an toàn phía máy chủ và thay bằng refresh token mới sau mỗi lần sử dụng (rotation).

D. (Nên tránh dùng) Implicit Grant và Resource Owner Password Credentials

OAuth 2.0 ban đầu định nghĩa Implicit Grant (cấp quyền ngầm định) trả token ngay qua URL fragment dành cho SPA, và ROPC (Resource Owner Password Credentials) trong đó client trực tiếp nhận ID · mật khẩu người dùng rồi chuyển tới máy chủ ủy quyền. Tuy nhiên, Implicit Grant dễ bị đánh cắp vì token bị lộ trong lịch sử trình duyệt · referrer và không có kiểm chứng kênh sau, còn ROPC khiến client trực tiếp xử lý mật khẩu người dùng, tái hiện lại chính vấn đề "chia sẻ mật khẩu" mà OAuth vốn muốn loại bỏ. Vì những lý do này, cả hai cách trên thực tế đã bị loại bỏ trong các tiêu chuẩn mới nhất, và OAuth 2.1 sẽ được trình bày ở phần sau đã xóa hoàn toàn cả hai khỏi đặc tả.

E. Tóm tắt so sánh các loại grant

Các grant đã trình bày ở trên (bốn loại và hai loại bị loại bỏ) nếu được sắp xếp theo hai trục "ai tham gia" và "client có thể lưu giữ an toàn bí mật không" thì tiêu chí lựa chọn sẽ trở nên rõ ràng.

Grant	Sự tham gia của người dùng	Client phù hợp	Hiện có được khuyến nghị không
Authorization Code(+PKCE)	Cần	Cả client công khai và bí mật	Khuyến nghị (mặc định)
Client Credentials	Không cần	Client bí mật (M2M)	Khuyến nghị
Refresh Token	Không cần (chỉ cần lần đầu)	Cả client công khai và bí mật	Khuyến nghị (bắt buộc xoay vòng)
Implicit	Cần	Client công khai	Loại bỏ (bị xóa trong OAuth 2.1)
ROPC	Cần (nhập trực tiếp mật khẩu)	Dùng cho chuyển đổi hệ thống cũ	Khuyến cáo loại bỏ

4. OpenID Connect: tầng xác thực trên OAuth

OIDC hoạt động bằng cách tái sử dụng nguyên luồng mã ủy quyền của OAuth 2.0, thêm scope=openid khi yêu cầu và bổ sung ID Token vào phản hồi. Tức là nó không phải là một giao thức mới riêng biệt mà là một phần mở rộng chuẩn (profile) của OAuth 2.0.

A. Cấu trúc của ID Token

ID Token là một JWT (JSON Web Token) có chữ ký, chứa các claim chuẩn như iss (bên phát hành), sub (định danh duy nhất của người dùng), aud (client là đối tượng nhận token), exp (thời điểm hết hạn), iat (thời điểm phát hành), nonce (số ngẫu nhiên chống tấn công phát lại), cùng các claim thuộc tính người dùng như name · email. Client kiểm chứng chữ ký của token này bằng khóa công khai của máy chủ ủy quyền, qua đó xác nhận bằng mật mã rằng token không bị giả mạo và được cấp cho chính mình (aud). Khả năng kiểm chứng chữ ký này là lý do căn bản để "dùng ID Token xác định việc đăng nhập là an toàn", điều mà access token đơn thuần (chuỗi không trong suốt hoặc chỉ máy chủ tài nguyên giải mã được) không thể làm được.

B. Endpoint UserInfo và khám phá (Discovery)

Khi thông tin trong ID Token là tối thiểu, client có thể mang access token tới endpoint chuẩn /userinfo để truy vấn thêm thuộc tính người dùng. Ngoài ra, máy chủ hỗ trợ OIDC công bố dưới dạng JSON chuẩn các địa chỉ endpoint ủy quyền · token · UserInfo, các thuật toán ký được hỗ trợ, danh sách scope được hỗ trợ thông qua tài liệu /.well-known/openid-configuration, nên thư viện client có thể tự động lấy thông tin liên kết mà không cần cấu hình riêng cho từng máy chủ.

Hạng mục	OAuth 2.0	OpenID Connect
Mục đích	Ủy quyền (ủy thác truy cập tài nguyên)	Xác thực (xác nhận danh tính) + ủy quyền
Token cốt lõi	Access Token, Refresh Token	ID Token (JWT) + token OAuth
Thông tin người dùng	Không có định nghĩa chuẩn	Claim của ID Token + `/userinfo`
Scope	Mỗi dịch vụ tự định nghĩa (`read`, `write`)	Scope chuẩn (`openid`,`profile`,`email`)
Khám phá	Không định nghĩa	`/.well-known/openid-configuration`
Dùng độc lập	Được (truy cập API M2M)	Không (bắt buộc dựa trên OAuth 2.0)

(Duende Software; SuperTokens)

C. Ba luồng (Flow) của OIDC

OIDC kế thừa nguyên các grant của OAuth và chia chi tiết thành ba luồng. Authorization Code Flow phù hợp với ứng dụng phía máy chủ, nhận an toàn cả ID Token và access token qua kênh sau. Implicit Flow trước đây trả token ngay qua kênh trước (front-channel) cho SPA, nhưng do các điểm yếu bảo mật đã nêu nên là đối tượng bị loại bỏ. Hybrid Flow là phương án dung hòa: nhận ID Token trước qua kênh trước ở bước phản hồi ủy quyền để hiển thị ngay tên người dùng trên màn hình, trong khi access token được nhận an toàn qua trao đổi kênh sau về sau; nó thường được dùng trong các kịch bản SSO doanh nghiệp cần giảm độ trễ chuyển màn hình sau khi chuyển hướng.

5. So sánh và tình huống áp dụng

Ví dụ quen thuộc nhất là đăng nhập mạng xã hội. Chẳng hạn, nếu một ứng dụng thương mại cung cấp nút "Đăng nhập bằng Google", sau khi người dùng xác thực · đồng ý tại máy chủ ủy quyền của Google, ứng dụng nhận từ Google ID Token (người dùng là ai) và, nếu cần, cả access token (quyền truy cập API bổ sung như Google Calendar · Drive). Khi đó, ứng dụng tuyệt đối không nhìn thấy mật khẩu Google, và người dùng có thể thu hồi riêng lẻ quyền truy cập của ứng dụng đó bất cứ lúc nào trong phần cài đặt tài khoản Google. Trong môi trường doanh nghiệp, mẫu chuẩn là liên kết IdP (Identity Provider) như Okta · Azure AD · Keycloak qua OIDC để hiện thực đăng nhập SSO bằng một tài khoản cho hàng chục hệ thống nội bộ, và lợi ích thực tiễn rõ rệt so với quản lý tài khoản riêng cho từng hệ thống là chỉ cần một lần xử lý nghỉ việc trong hệ thống nhân sự là có thể đồng thời chặn truy cập vào mọi hệ thống liên kết. Ngược lại, với liên kết batch giữa các máy chủ (ví dụ: dịch vụ thanh toán nội bộ gọi API của dịch vụ quyết toán mỗi giờ), vì không có sự tham gia của người dùng nên phù hợp với Client Credentials Grant của OAuth thuần túy chứ không phải OIDC, và nếu gượng ép đưa khái niệm danh tính người dùng vào thì thiết kế lại càng phức tạp.

6. Liên kết với đề thi cũ và chủ đề tương tự

Chủ đề này thường xuất hiện trong kỳ thi Kỹ sư chuyên nghiệp Quản lý Thông tin cả dưới dạng câu hỏi độc lập lẫn luận điểm phụ của các chủ đề khác. Nó liên kết với các chủ đề "định danh và xác thực", "JWT", "kiểm soát truy cập (Access Control)", "mô hình bảo mật zero trust" theo quan hệ là tiêu chuẩn hiện thực cụ thể của xác thực · ủy quyền, và trong các chủ đề "bảo mật truyền dữ liệu MyData" · "SLA đám mây tài chính", FAPI được trích dẫn như căn cứ kỹ thuật của các yêu cầu pháp quy thực tế. Khi xây dựng bài làm, nếu triển khai theo mạch "khái niệm OAuth/OIDC → tiêu chí chọn grant → tăng cường bảo mật mới nhất (OAuth 2.1 · FAPI) → áp dụng vào kiến trúc zero trust · microservice", có thể vượt qua mức giải thích giao thức đơn thuần để tự nhiên bao gồm cả góc nhìn kiến trúc · quản trị mà bài làm của Kỹ sư chuyên nghiệp đòi hỏi.

7. Chuyên sâu — Xu hướng mới nhất và các tiêu chuẩn tăng cường bảo mật

Hệ sinh thái OAuth đang tiến hóa nhanh từ những năm 2020 theo hướng làm cho "chính giá trị mặc định trở nên an toàn hơn".

OAuth 2.1: Là công việc hợp nhất nhiều khuyến nghị bảo mật (các RFC) nằm rải rác sau RFC 6749 thành một đặc tả duy nhất, bắt buộc PKCE cho mọi client (cả công khai lẫn bí mật), và xóa hoàn toàn Implicit Grant và ROPC khỏi đặc tả — những thứ liên tục bị chỉ ra lỗ hổng. Ngoài ra, nó bắt buộc URI chuyển hướng phải khớp chính xác nguyên chuỗi (exact match) và yêu cầu xoay vòng (rotation) refresh token (OAuth.net; WorkOS).
FAPI (Financial-grade API): Là profile do OpenID Foundation áp thêm các ràng buộc lên OAuth/OIDC dành cho các API rủi ro cao như lĩnh vực tài chính. Nó yêu cầu mTLS hoặc JWT có chữ ký (private_key_jwt) thay cho khóa bí mật để xác thực client, và ràng buộc access token với chứng chỉ client (sender-constrained token) để ngăn tái sử dụng ngay cả khi token bị đánh cắp (OpenID Foundation FAPI). Các yêu cầu bảo mật API của Open Banking · MyData tại Hàn Quốc cũng theo triết lý tương tự (xác thực client mạnh, ràng buộc token).
DPoP (Demonstrating Proof of Possession): Là phần mở rộng yêu cầu client ở mỗi yêu cầu phải xuất trình kèm một giá trị chứng minh được ký bằng khóa riêng mà chỉ mình biết, để dù access token bị đánh cắp thì kẻ tấn công cũng không thể tái sử dụng nguyên vẹn; nó đang được chú ý như phương án thay thế để hiện thực ràng buộc token trong môi trường khó dùng mTLS (SPA, di động).

8. Những điểm cần cân nhắc và hàm ý (dưới góc nhìn Kỹ sư chuyên nghiệp)

Nguyên tắc thiết kế kiến trúc: Trong môi trường microservice · API gateway, thiết kế vừa bảo đảm khả năng bảo trì vừa bảo đảm bảo mật là tập trung hóa xác thực (xác nhận danh tính) bằng OIDC, còn ủy quyền giữa các dịch vụ riêng lẻ thì tách thành chính sách chi tiết dựa trên scope · claim. Nếu mỗi dịch vụ tự hiện thực logic xác thực, lỗ hổng do chênh lệch hiện thực tất yếu sẽ phát sinh.
Đánh đổi: Các biện pháp tăng cường như PKCE · mTLS · ràng buộc token nâng cao bảo mật nhưng làm tăng độ phức tạp hiện thực phía client và gánh nặng hạ tầng (quản lý chứng chỉ v.v.). Nếu áp dụng đồng loạt kiểm soát cấp tài chính (FAPI) cho cả những vùng có mô hình đe dọa tương đối thấp như giao tiếp M2M trong mạng nội bộ thì sẽ thành thiết kế thừa, vì vậy phải phân tầng mức kiểm soát theo độ nhạy cảm của tài nguyên.
Liên kết với zero trust: Nguyên tắc của OAuth/OIDC "kiểm chứng token và scope hợp lệ ở mỗi yêu cầu" khớp chính xác với tiền đề cốt lõi của mô hình bảo mật zero trust (loại bỏ tin cậy ngầm định, kiểm chứng liên tục). Đặc biệt, thời hạn access token ngắn và scope chi tiết là hiện thân thực tế của nguyên tắc đặc quyền tối thiểu (least privilege) giúp giảm thiểu phạm vi thiệt hại khi xảy ra sự cố.
Triển vọng — ủy quyền trong thời đại AI agent: Gần đây, khi các trường hợp LLM agent tự động gọi nhiều API thay mặt người dùng tăng lên, các mô hình ủy quyền ủy thác biểu diễn "agent có thể hành động thay mặt đến phạm vi nào, trong bao lâu" (ví dụ: đăng ký client động, Rich Authorization Requests chi tiết, token thời hạn ngắn cho từng agent) đang nổi lên như điểm mở rộng mới của hệ sinh thái OAuth. Dưới góc độ ôn thi Kỹ sư chuyên nghiệp Quản lý Thông tin, việc mô hình ủy thác ba bên hiện có (người dùng-client-máy chủ) sẽ tiếp nhận an toàn tác nhân thứ tư là "agent không phải con người" như thế nào sẽ là lĩnh vực quan trọng cả trong ra đề lẫn thực tiễn sắp tới.
Góc nhìn kiểm toán · log: Lịch sử cấp · làm mới · thu hồi token của máy chủ ủy quyền, việc có hiển thị màn hình đồng ý hay không, lịch sử thay đổi scope là bằng chứng thiết yếu cho cả việc tuân thủ chính sách xử lý thông tin cá nhân lẫn ứng phó sự cố (forensic). Trong giám định hệ thống thông tin · thẩm định ISMS-P, "có truy vết được ai đã ủy thác khi nào với phạm vi nào không" cũng được coi là hạng mục kiểm tra cốt lõi của hệ thống xác thực · ủy quyền, vì vậy cần xây dựng cơ chế ghi log sự kiện token ngay từ đầu giai đoạn thiết kế.
Tính sẵn sàng · cách ly sự cố: Máy chủ ủy quyền trên thực tế trở thành điểm tin cậy duy nhất của toàn bộ hệ thống doanh nghiệp (cấu trúc gần với SPOF), nên sự cố máy chủ ủy quyền đồng nghĩa với việc không thể đăng nhập toàn bộ. Cần cân nhắc riêng thiết kế tính sẵn sàng như cấu hình đa vùng (multi-region), duy trì kiểm chứng token ngoại tuyến bằng khóa công khai đã lưu đệm.

Tài liệu tham khảo

Với các căn cứ đa chiều như vậy, khi viết bài làm Kỹ sư chuyên nghiệp thực tế, không nên dừng ở câu đơn giản "OAuth và OIDC khác nhau", mà phải trình bày kèm cấu trúc và xu hướng tăng cường bảo mật đã nêu ở trên thì mới thể hiện đúng góc nhìn thực tiễn · thẩm định.

Tóm tắt một câu: OAuth 2.0 là khung ủy quyền ủy thác quyền truy cập có phạm vi giới hạn mà không làm lộ mật khẩu người dùng, OpenID Connect là tầng xác thực đặt trên đó để chứng minh "ai đã đăng nhập" bằng ID Token có chữ ký, và các tiêu chuẩn tăng cường mới như PKCE · FAPI · OAuth 2.1 đang tiếp tục tiến hóa để đối phó với mối đe dọa đánh cắp · tái sử dụng token.