OpenID Connect là gì? Cách hoạt động và phân biệt OAuth 2.0

OpenID Connect là gì và dùng để làm gì?

OpenID Connect là gì là câu hỏi phổ biến khi lập trình viên xây dựng chức năng đăng nhập bằng tài khoản bên thứ ba hoặc tích hợp nền tảng như Zalo vào ứng dụng. OpenID Connect, viết tắt là OIDC, là một lớp xác thực danh tính được xây dựng trên OAuth 2.0. Giao thức này giúp ứng dụng xác định người dùng vừa đăng nhập là ai và nhận một số thông tin hồ sơ theo cách tiêu chuẩn.

OAuth 2.0 được thiết kế để cấp quyền truy cập tài nguyên. Ví dụ, người dùng cho phép ứng dụng đọc hồ sơ hoặc gọi API thay mặt họ. Tuy nhiên, chỉ có access token chưa đủ để kết luận chắc chắn danh tính người dùng. OIDC bổ sung ID token, các claim tiêu chuẩn và quy trình kiểm tra nhằm giải quyết bài toán xác thực.

Trong một hệ thống OIDC thường có ba thành phần:

• End User: Người dùng thực hiện đăng nhập.
• Relying Party: Ứng dụng cần xác thực người dùng.
• OpenID Provider: Nhà cung cấp danh tính thực hiện đăng nhập và phát hành token.

OIDC được dùng trong đăng nhập một lần, ứng dụng web, mobile app, hệ thống SaaS và cổng quản trị. Khi triển khai đúng, ứng dụng không cần tự xây toàn bộ cơ chế xác thực riêng cho từng nhà cung cấp.

OIDC giải quyết vấn đề gì?

Một ứng dụng thường có hai nhu cầu. Nhu cầu thứ nhất là xác minh danh tính, chẳng hạn biết tài khoản nào đang đăng nhập. Nhu cầu thứ hai là xin quyền truy cập dữ liệu hoặc chức năng, chẳng hạn đọc hồ sơ hoặc gọi API.

OpenID Connect xử lý nhu cầu xác thực danh tính. OAuth 2.0 xử lý nhu cầu cấp quyền. Hai giao thức có thể xuất hiện trong cùng một quy trình nhưng không nên bị xem là một.

OpenID Connect được xây trên OAuth 2.0 như thế nào?

OIDC không thay thế OAuth 2.0 mà mở rộng giao thức này. Nó sử dụng các thành phần quen thuộc như authorization endpoint, token endpoint, client ID, redirect URI, scope, authorization code và access token. Điểm khác biệt quan trọng là OIDC bổ sung scope openid và ID token.

Khi ứng dụng gửi yêu cầu có scope openid, nhà cung cấp hiểu rằng đây là yêu cầu xác thực chứ không chỉ cấp quyền. Sau khi người dùng đăng nhập thành công, hệ thống trả về authorization code. Ứng dụng đổi code tại token endpoint để nhận ID token, access token và đôi khi có refresh token.

Ngoài openid, ứng dụng có thể yêu cầu các scope như profile, email hoặc phone. Những scope này cho biết loại thông tin người dùng mà ứng dụng muốn nhận. Việc có được dữ liệu hay không còn phụ thuộc sự đồng ý của người dùng và chính sách nhà cung cấp.

Các endpoint thường gặp

Một nhà cung cấp OIDC thường có authorization endpoint để đăng nhập, token endpoint để đổi code lấy token, UserInfo endpoint để lấy hồ sơ, JWKS endpoint để cung cấp khóa công khai và discovery endpoint để công bố cấu hình.

ID token là gì và khác access token ra sao?

ID token là thành phần trung tâm của OIDC. Đây là token chứa thông tin về kết quả xác thực người dùng, thường có định dạng JWT gồm header, payload và signature.

Payload có thể chứa các claim quan trọng:

• iss: Nhà phát hành token.
• sub: Mã định danh người dùng tại nhà phát hành.
• aud: Ứng dụng được phép nhận token.
• exp: Thời điểm token hết hạn.
• iat: Thời điểm token được phát hành.
• nonce: Giá trị chống phát lại yêu cầu.

Ứng dụng dùng ID token để kiểm tra danh tính và thiết lập phiên đăng nhập nội bộ. Token này không được thiết kế để thay thế access token khi gọi API.

Access token có mục đích khác. Nó được dùng để truy cập tài nguyên được bảo vệ theo phạm vi đã cấp. Khi ứng dụng gọi API lấy hồ sơ, dữ liệu hoặc thực hiện hành động thay mặt người dùng, access token thường được gửi kèm yêu cầu.

Vì sao không nên dùng nhầm token?

Một lỗi phổ biến là giải mã access token rồi lấy một trường bên trong làm danh tính người dùng. Cách này không an toàn vì access token có thể là chuỗi không cấu trúc, có đối tượng nhận khác hoặc không chứa claim danh tính ổn định.

Ngược lại, dùng ID token để gọi API cũng không đúng mục đích. Có thể nhớ đơn giản: ID token trả lời người dùng là ai, còn access token trả lời ứng dụng được phép làm gì.

Luồng xác thực OpenID Connect hoạt động ra sao?

Luồng phổ biến nhất là Authorization Code Flow. Với ứng dụng mobile hoặc single-page application, luồng này thường kết hợp PKCE để giảm nguy cơ authorization code bị đánh cắp.

Quy trình cơ bản gồm:

1. Người dùng chọn đăng nhập bằng nhà cung cấp danh tính.
2. Ứng dụng tạo state, nonce và thông tin PKCE nếu cần.
3. Trình duyệt được chuyển đến authorization endpoint.
4. Người dùng đăng nhập và chấp thuận quyền truy cập.
5. Nhà cung cấp chuyển về redirect URI kèm authorization code.
6. Backend đổi code lấy token tại token endpoint.
7. Nhà cung cấp trả ID token, access token và có thể có refresh token.
8. Ứng dụng kiểm tra ID token rồi tạo phiên đăng nhập nội bộ.

state giúp liên kết yêu cầu ban đầu với callback và chống giả mạo yêu cầu. nonce giúp ngăn ID token cũ bị phát lại. Hai giá trị này cần đủ ngẫu nhiên, được lưu tạm và chỉ sử dụng một lần.

Kiểm tra ID token đúng cách

Ứng dụng không nên chỉ giải mã JWT rồi tin vào dữ liệu bên trong. Cần kiểm tra chữ ký bằng khóa công khai, đối chiếu iss, bảo đảm aud chứa client ID, kiểm tra exp, xác minh nonce và chỉ chấp nhận thuật toán ký phù hợp.

Sau khi token hợp lệ, ứng dụng có thể dùng sub làm định danh người dùng. Không nên mặc định dùng email làm khóa chính vì email có thể thay đổi, bị ẩn hoặc chưa được xác minh.

PKCE có vai trò gì?

PKCE dùng code verifier và code challenge để bảo vệ bước đổi authorization code lấy token. Cơ chế này đặc biệt quan trọng với mobile app, SPA hoặc client không thể giữ bí mật client secret.

OpenID Connect khác gì OAuth 2.0?

Điểm khác biệt cốt lõi nằm ở mục tiêu. OAuth 2.0 là khung ủy quyền, còn OpenID Connect là giao thức xác thực danh tính xây trên khung đó.

OAuth 2.0 trả lời câu hỏi: Ứng dụng được phép truy cập tài nguyên nào? OIDC trả lời câu hỏi: Người dùng vừa đăng nhập là ai?

Ví dụ, một ứng dụng bán hàng cho phép người dùng đăng nhập bằng tài khoản bên thứ ba. Việc biết mã định danh người dùng là bài toán OIDC. Sau đó, ứng dụng muốn gọi API lấy dữ liệu đã được cấp quyền thì dùng access token của OAuth 2.0.

Ứng dụng khi tích hợp Zalo API và hệ thống thực tế

Khi tích hợp Zalo API hoặc một nền tảng khác, lập trình viên cần kiểm tra chính xác dịch vụ đang hỗ trợ OAuth 2.0, OIDC hay cơ chế riêng. Không nên thấy authorization code và access token rồi mặc định kết luận đó là OpenID Connect.

Một hệ thống chỉ được xem là OIDC khi có các thành phần cốt lõi như scope openid, ID token, issuer và cơ chế xác minh token tiêu chuẩn. Nếu nhà cung cấp chỉ trả access token để gọi API lấy hồ sơ, đó có thể là đăng nhập dựa trên OAuth 2.0 nhưng chưa phải OIDC hoàn chỉnh.

Mô hình triển khai phù hợp với ứng dụng có backend thường là:

1. Backend tạo URL đăng nhập cùng state, nonce và PKCE.
2. Người dùng đăng nhập tại nhà cung cấp.
3. Callback được xử lý tại backend.
4. Backend đổi authorization code lấy token.
5. Backend xác minh ID token nếu có.
6. Hệ thống ánh xạ iss + sub với tài khoản nội bộ.
7. Backend tạo session hoặc token riêng cho ứng dụng.
8. Access token bên thứ ba được lưu an toàn nếu còn cần gọi API.

Không nên gửi client secret xuống trình duyệt hoặc mobile app. Cũng không nên dùng trực tiếp access token của nhà cung cấp làm token đăng nhập nội bộ nếu chưa đánh giá kỹ audience, thời hạn và phạm vi sử dụng.

Ví dụ luồng đăng nhập

Giả sử cổng quản trị cho phép đăng nhập bằng tài khoản doanh nghiệp. Sau callback, backend kiểm tra ID token, lấy sub làm mã định danh và tìm tài khoản tương ứng trong cơ sở dữ liệu.

Nếu tài khoản chưa tồn tại, hệ thống có thể tạo mới sau khi kiểm tra các trường cần thiết. Nếu đã tồn tại, backend tạo phiên đăng nhập nội bộ. Khi cần gọi API bên thứ ba, backend sử dụng access token thay vì ID token.

Lưu ý bảo mật và kết luận

Redirect URI phải được đăng ký chính xác và so khớp chặt chẽ. Không nên cho phép redirect URI tùy ý hoặc kiểm tra bằng chuỗi gần đúng vì có thể dẫn đến đánh cắp authorization code.

Ứng dụng phải kiểm tra state, nonce, chữ ký, issuer, audience và thời gian hết hạn. Khóa công khai cần được lấy từ nguồn tin cậy, hỗ trợ xoay vòng theo kid và không chấp nhận tùy ý thuật toán do token chỉ định.

Token cần được lưu đúng vị trí. Backend nên hạn chế quyền truy cập vào token nhạy cảm. Cookie phiên nên dùng Secure, HttpOnly và SameSite phù hợp. Ứng dụng cũng cần xử lý đăng xuất, thu hồi quyền, token hết hạn và refresh token theo chính sách nhà cung cấp.

Tóm lại, câu trả lời cho OpenID Connect là gì là: đây là giao thức xác thực danh tính được xây dựng trên OAuth 2.0. OIDC bổ sung ID token và các quy tắc tiêu chuẩn để ứng dụng biết người dùng vừa đăng nhập là ai. OAuth 2.0 tập trung vào cấp quyền, còn OIDC tập trung vào xác thực bên cạnh zalo web đăng nhập.

Khi tích hợp Zalo API hoặc nền tảng bên thứ ba, lập trình viên cần xác định đúng chuẩn được hỗ trợ, dùng đúng loại token và kiểm tra đầy đủ trước khi tin cậy dữ liệu người dùng. Việc phân biệt rõ OIDC với OAuth 2.0 giúp hệ thống dễ bảo trì, an toàn hơn và tránh nhiều lỗi thiết kế phổ biến.

Vương Minh

Vương Minh – người dẫn dắt và đứng sau sự thành công của ZALO Web cùng với đội ngũ kĩ sư ưu tú nhất. Với khát vọng tạo ra một sản phẩm công nghệ “Make in Vietnam” đủ sức cạnh tranh sòng phẳng với các đối thủ quốc tế, ông Khải cùng các cộng sự tại Zalo Group đã không ngừng cải tiến để Zalo không chỉ là app nhắn tin mà còn là một hệ sinh thái làm việc đa nền tảng. Zalo Web chính là minh chứng cho triết lý đó: tinh gọn, tốc độ và thấu hiểu sâu sắc thói quen của người dùng Việt.