Đang xử lý.....

Tiêu chuẩn lõi kết nối OpenID (Phần 2)  

OpenID Connect Core 1.0
Thứ Sáu, 02/10/2020 |  1478
|

Ở phần 1, bài viết đã giới thiệu tổng quan và đưa ra các khái niệm cơ bản của tiêu chuẩn OpenID Connect 1.0. Để tiếp nối, phần 2 sẽ chia sẻ tiếp các cấu phần hình thành quá trình xử lý trong tiêu chuẩn OpenID Connect 1.0. 

Hình 1: Một đoạn id token trong code JSON

6. Xác thực máy chủ RP

Phần này xác định một tập hợp các phương thức xác thực máy chủ RP nhằm xác thực với máy chủ ủy quyền khi sử dụng mã thông báo ở endpoint. Trong quá trình đăng ký trên máy chủ RP, máy chủ RP CÓ THỂ đăng ký một phương thức xác thực cho chính nó. Nếu không có phương thức nào được đăng ký, phương thức mặc định là “client_secret_basic”.

Các phương thức xác thực ứng dụng trên máy chủ RP là:

Tên

Giải thích

client_secret_basic

Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền nhằm xác thực với máy chủ ủy quyền bằng cách sử dụng sơ đồ xác thực HTTP Basic. Các bước tương tự mục 2.3.1 của Oauth 2.0 [RFC6749]

client_secret_post

Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền, xác thực với máy chủ ủy quyền bằng cách đưa thông tin xác thực của máy chủ RP vào phần thân của yêu cầu

client_secret_jwt

Máy chủ RP đã nhận được giá trị “client_secret” từ máy chủ ủy quyền tạo JWT dùng các thuật toán HMAC SHA, chẳng hạn như là HMAC SHA-25. HMAC (mã xác thực tin nhắn dựa trên Hash) được tính bằng cách sử dụng các octet của đại diện UTF-8 thuộc “client_secret” làm khóa chia sẻ

private_key_jwt

Máy chủ RP đã đăng ký khóa công khai ký JWT bằng chính khóa này. Máy chủ RP xác thực theo JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.JWT] và Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [OAuth.Assertions].

JWT có thể chứa các giá trị khác về các khối thông tin như ở mã thông báo ID, bất kỳ giá trị nào không được hiểu PHẢI bỏ qua. Mã thông báo xác thực PHẢI được gửi dưới dạng giá trị của tham số “client_asserts”. Giá trị của tham số “client_assert_type” phải là “urn; ietf; params; … ”.

None

Máy chủ RP không tự xác thực tại mã thông báo ở điểm cuối, vì nó chỉ sử dụng luồng ẩn (và do đó không sử dụng mã thông báo ở điểm cuối) hoặc vì đó là máy chủ công cộng không có mã bí mật dùng để xác thực ứng dụng hoặc do có cơ chế xác thực khác.

Trong đó với phương thức xác thực “client_secret_jwt” và “private_key_jwt” thì JWT PHẢI chứa các giá trị yêu cầu BẮT BUỘC hoặc là CÓ THỂ chứa các yêu cầu nằm trong bảng dưới đây:

iss

CẦN THIẾT, viết tắt cho “issuer”. Nó phải chứa “client_id” của máy chủ OAuth.

sub

CẦN THIẾT, viết tắt cho “subject”. Nó phải chứa “client_id” của máy chủ OAuth.

aud

CẦN THIẾT, viết tắt cho “Audience”. Giá trị xác định cho máy chủ ủy quyền như là một đối tượng dự định. Máy chủ ủy quyền PHẢI xác định rằng đối tượng này có mã thông báo. Nó NÊN là URL của mã thông báo ở điểm cuối được tạo bởi máy chủ ủy quyền.

jti

CẦN THIẾT, viết tắt cho “JWT ID”. Một mã định danh duy nhất cho mã thông báo, có thể được sử dụng để ngăn việc sử dụng lại mã thông báo. Các mã thông báo này PHẢI được sử dụng một lần, trừ khi các điều kiện để sử dụng lại được đàm phán giữa các bên.

exp

CẦN THIẾT, thời gian hết hạn vào hoặc sau đó mã thông báo ID KHÔNG ĐƯỢC đồng ý cho quá trình xử lý.

iat

KHÔNG BẮT BUỘC. Thời gian mà JWT được ban hành.

7. Đăng nhập từ bên thứ ba

Trong một số trường hợp, luồng đăng nhập được bắt đầu bởi nhà cung cấp OpenID hoặc một bên khác thay vì là từ máy chủ RP. Trong trường hợp này, bộ khởi tạo chuyển hướng đến RP tại điểm truy cập của nó ví dụ là trình duyệt của người dùng, yêu cầu RP gửi một yêu cầu xác thực sang phía máy chủ xác thực OP. Điểm cuối bắt đàu đăng nhập này có thể là một liên kết sâu trên máy chủ RP, chứ không phải là một trang đích mặc định. Máy chủ RP khi này sẽ hỗ trợ OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration] đăng ký giá trị thiết bị đầu cuối bằng cách sử dụng giá trị tham số đăng ký “initiate_login_uri”.

Tại đây, bên bắt đầu yêu cầu đăng nhập sẽ bắt đầu quá trình đăng nhập bằng cách chuyển hướng đến điểm cuối bắt đăng nhập tại máy chủ RP, đồng thời truyền các tham số sau:

iss

Giá trị này là CẦN THIẾT. Mã định danh nhà phát hành cho OP rằng máy chủ RP sẽ gửi yêu cầu xác thực tới. Giá trị của nó PHẢI là một URL sử dụng lược đồ “https”.

login_hint

Giá trị này là KHÔNG BẮT BUỘC. Gợi ý cho máy chủ ủy quyền về số nhận dạng đăng nhập mà Người dùng cuối có thể sử dụng để đăng nhập. Nếu ứng dụng nhận được giá trị cho tham số có giá trị chuỗi này, thì PHẢI đưa nó vào yêu cầu xác thực làm giá trị tham số login_hint.

target_link_uri

Giá trị này là KHÔNG BẮT BUỘC. URL mà RP được yêu cầu chuyển hướng đến sau khi xác thực. RP PHẢI xác minh giá trị của target_link_uri để tránh bị sử dụng làm công cụ chuyển hướng mở cho các trang web bên ngoài.

Các tham số có thể được truyền dưới dạng tham số truy vấn bằng phương thức HTTP GET hoặc được truyền dưới dạng giá trị biểu mẫu HTML được gửi tự động trong phần mềm mà người dùng tham gia vào quá trình xác thực khi tương tác với sever và do đó được truyền qua phương thức POST HTTP.

Các tham số khác CÓ THỂ được gửi, nếu được xác định bởi các phần mở rộng. Bất kỳ tham số nào được sử dụng không hiểu được PHẢI được máy chủ RP bỏ qua.

Máy chủ RP NÊN sử dụng tính năng chặn khung và các kỹ thuật khác để ngăn người dùng cuối đăng nhập bởi các trang web của bên thứ ba mà họ không biết thông qua các cuộc tấn công như Clickjacking (một kỹ thuật độc hại để lừa người dùng nhấn vào và bị một hành động nào đó đánh cắp thông tin người dùng từ phía OP).

8. Chữ ký và mã hóa

Tùy thuộc vào việc truyền tải thông điệp được gửi đi, tính toàn vẹn của tin nhắn có thể không được đảm bảo và người khởi tạo tin nhắn có thể không được xác thực. Để giảm thiểu những rủi ro về thiếu tính xác thực các giá trị JWT như: mã thông báo ID, phản hồi của người dùng, đối tượng yêu cầu và xác thực ứng dụng khách thì các giá trị này có thể sử dụng JSON Web Signature (JWS) để ký nội dung của chúng. Để đạt được bảo mật thông điệp, các giá trị này cũng có thể sử dụng JSON Web Encryption (JWE) để mã hóa nội dung của chúng.

Khi tin nhắn được ký và mã hóa, nó PHẢI được ký trước và sau đó được mã hóa, với kết quả là JWT lồng nhau, như được chỉ định trong JWT. Lưu ý rằng tất cả các phương thức mã hóa JWE thực hiện kiểm tra tính toàn vẹn.

Phía máy chủ OP công bố các thuật toán mã hóa và ký được hỗ trợ trong tài liệu discovery của mình hoặc có thể cung cấp thông tin này bằng các phương tiện khác. Phía máy chủ RP tuyên bố các thuật toán ký và mã hóa được yêu cầu trong “yêu cầu đăng ký động” hoặc có thể truyền đạt thông tin này bằng các phương tiện khác.

a. Chữ ký

Bên ký phải chọn một thuật toán chữ ký dựa trên 2 thuật toán dưới đây được bên nhận hỗ trợ:

Hình 2 : Quá trình trao đổi mã khóa

Chữ ký bất đối xứng (Asymmetric Signatures)

Khi sử dụng Chữ ký RSA hoặc ECDSA, giá trị Tham số tiêu đề "alg" của tiêu đề JOSE PHẢI được đặt thành một thuật toán thích hợp như được xác định trong JSON Web Algorithms [JWA]. Khóa riêng được sử dụng để ký nội dung PHẢI được liên kết với khóa chung được sử dụng để xác minh chữ ký được gửi bởi người gửi trong tài liệu JWK Set của nó. Nếu có nhiều phím trong tham chiếu JWK Set tài liệu, giá trị "kid" phải được cung cấp trong JOSE Header. Việc sử dụng khóa của các khóa tương ứng PHẢI hỗ trợ ký.

Chữ ký đối xứng (Symmetric Signatures)

Khi sử dụng chữ ký dựa trên mã xác thực mẩu tin (MAC), giá trị tham số tiêu đề "alg" của JOSE Header PHẢI được đặt thành thuật toán MAC, như được xác định trong JSON Web Algorithms [JWA]. Khóa MAC được sử dụng là các octet của biểu diễn UTF-8 của giá trị "client_secret". Chữ ký đối xứng KHÔNG được sử dụng bởi các ứng dụng công cộng (không bảo mật) vì không thể giữ bí mật.

b. Mã hóa

Bên mã hóa PHẢI chọn một thuật toán mã hóa dựa trên các thuật toán được phía bên nhận hỗ trợ theo 3 loại mã sau:

Mã hóa bất đối xứng: RSA

Khóa công khai mà nội dung được mã hóa PHẢI là khóa chung được sử dụng để mã hóa được người nhận xuất bản trong tài liệu JWK Set của nó. Nếu có nhiều mã khóa trong tham chiếu JWK Set. Việc sử dụng khóa của các khóa tương ứng PHẢI có sự mã hóa.

Mã hóa bất đối xứng: đường ong Elliptic

Tạo khóa công khai Elliptic Curve phù hợp cho phần tử “epk” của Tiêu đề JOSE. Khóa công khai khác được sử dụng cho tính toán thỏa thuận khóa PHẢI là khóa chung được công bố bởi người nhận trong tài liệu JWK Set của nó. Sử dụng thuật toán ECDH-ES để thống nhất Khóa mã hóa nội dung được sử dụng để mã hóa JWT đã ký. Việc sử dụng khóa của các khóa tương ứng PHẢI hỗ trợ mã hóa.

Mã hóa đối xứng

Khóa mã hóa đối xứng được lấy từ giá trị “client_secret” bằng cách sử dụng hàm băm SHA-2 bị cắt ngắn của các octet của biểu diễn UTF-8 của “client_secret”. Đối với các khóa từ 256 bit trở xuống, SHA-256 được sử dụng; đối với các khóa gồm 256-384 bit, SHA-384 được sử dụng; đối với các khóa 385-512 bit, SHA-512 được sử dụng. Giá trị băm PHẢI được cắt ngắn đến độ dài bit thích hợp cho gói khóa AES hoặc thuật toán mã hóa trực tiếp được sử dụng, ví dụ, cắt băm SHA-256 thành 128 bit cho A128KW. Nếu cần một khóa đối xứng có lớn hơn 512 bit, thì một phương pháp khác để lấy khóa từ “client_secret” sẽ phải được xác định bởi một phần mở rộng. Mã hóa đối xứng KHÔNG được sử dụng bởi các Khách hàng công cộng (không bảo mật) vì không thể giữ bí mật.

9. Truy cập ngoại tuyến

OpenID CC 1.0 xác định giá trị “scope” để yêu cầu ngoại tuyến theo giá trị sau:

offine_access

Đây là giá trị KHÔNG BẮT BUỘC. Giá trị “scope” này yêu cầu rằng một mã thông báo làm mới OAuth 2.0 được máy chủ nào đó phát hành có thể dùng để có được mã truy cập mới và truy cập vào điểm truy cập cuối với thông tin người dùng ngay cả khi người dùng này không có mặt (không truy cập).

Khi mà truy cập ngoại tuyến được yêu cầu, một giá trị tham số “prompt” của “consent” PHẢI được sử dụng. Trường hợp người dùng có đủ các điều kiện để máy chủ ủy quyền xử lý yêu cầu cho phép truy cập ngoại tuyến vào các tài nguyên thì máy chủ ủy quyền PHẢI luôn nhận được sự đồng ý để trả lại một mã thông báo truy cập mới nhằm cho phép truy cập ngoại tuyến vào tài nguyên đã được yêu cầu. Sự đồng ý của người dùng đã lưu trước đây không phải lúc nào cũng đủ để cấp quyền truy cập ngoại tuyến.

Khi nhận được một giá trị “offine_access”, máy chủ ủy quyền:

- PHẢI đảm bảo rằng tham số có chứa giá trị “consent” trừ khi có các điều kiện khác để xử lý yêu cầu cho phép truy cập ngoại tuyến như nói ở trên. Nếu có đủ điều kiện được đáp ứng với yêu cầu của máy chủ ủy quyền thì máy chủ sẽ bỏ qua yêu cầu “offine_access”

- PHẢI bỏ qua giá trị “offine_access” trừ khi máy chủ RP sử dụng một giá trị “respone_type” mà sẽ có kết quả trong mã ủy quyền được trả lại.

- PHẢI phản hồi một cách rõ ràng hoặc có sự đồng ý từ tất cả máy chủ uy tín khi đăng ký với giá trị “application_type” là “web”.

- NÊN phải hồi một cách rõ ràng hoặc có sự đồng ý từ tất cả máy chủ uy tín khi đăng ký với giá trị “application_type” là “native”.

Việc sử dụng mã thông báo làm mới không dành riêng cho trường hợp sử dụng “offine_access”. Máy chủ ủy quyền có thể cấp mã thông báo làm mới trong một các trường hợp khác mà nằm ngoài phạm vi của điều kiện kỹ thuật này.

10. Sử dụng mã thông báo làm mới

Để mã thông báo ở Endpoint được yêu cầu có thể sử dụng một mã thông báo làm mới là sử dụng giá trị “grant_type” là “fresh_token”. Để làm mới mã thông báo truy cập, máy chủ RP PHẢI xác thực với mã thông báo ở Endpoint bằng phương thức xác thực được đăng ký cho “client_id” của nó. Máy chủ RP gửi các tham số qua HTTP POST đến mã thông báo ở Endpoint bằng cách sử dụng tuần tự hóa biểu mẫu.

Máy chủ ủy quyền PHẢI xác thực mã thông báo làm mới. Tiếp đó nó PHẢI xác minh rằng nó đã được cấp quyền cho máy chủ RP và phải chắc chắn rằng máy chủ RP đã xác thực thành công với phương thức xác thực ứng dụng của phía máy chủ RP cấp.

Sau khi xác thực thành công mã thông báo làm mới, phần nội dung phản hồi chính là mã phản hồi thông báo (Token Response) ngoài trừ việc nó có thể không chứa “id_token”.

Nếu mã thông báo ID được trả về do yêu cầu làm mới từ mã thông báo, các yêu cầu được áp dụng như sau:

- Giá trị “iss” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.

- Giá trị “sub” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.

- Giá trị “iat” PHẢI thể hiện thời gian mã thông báo ID mưới được phát hành.

- Giá trị “aud” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra.

- Nếu Mã thông báo ID chứa xác nhận “auth_time”, giá trị của nó PHẢI biểu thị thời gian xác thực ban đầu - không phải là thời gian mã thông báo ID mới được phát hành.

- Giá trị “azp” PHẢI giống như trong mã thông báo ID được cấp khi xác thực ban đầu xảy ra, nếu không có giá trị “azp” nào xuất hiện trong mã thông báo ID gốc, thì IKHÔNG PHẢI xuất hiện trong mã thông báo ID mới và nếu không, các quy tắc tương tự sẽ được áp dụng khi áp dụng Mã thông báo ID tại thời điểm xác thực ban đầu.

Trong trường hợp yêu cầu làm mới không hợp lệ hoặc trái phép, máy chủ ủy quyền sẽ trả về phản hồi mã lỗi phản hồi (Token Error Response).

11. Tuần tự hóa và hoạt động theo chuỗi

Các nội dung trao đổi được tuần tự hóa bằng một trong các phương pháp sau:

- Chuỗi tuần tự truy vấn

- Biểu mẫu nối tiếp

- Tuần tự hóa JSON

Khi xử lý một số nội dung trao đổi, OpenID CC 1.0 yêu cầu so sánh các giá trị trong nội dung này với những giá trị đã biết. Ví du là so sánh các chuỗi Unicode, nó có ý nghĩa bảo mật quan trọng.

Do đó việc so sánh giữa các chuỗi JSON và các chuỗi Unicode khác PHẢI được thực hiện như theo chỉ định dưới đây:

- Xóa mọi JSON được áp dụng thoát để tạo ra một loạt các điểm mã Unicode.

- Chuẩn hóa Unicode [USA 15] KHÔNG được áp dụng tại bất kỳ điểm nào đối với chuỗi JSON hoặc chuỗi được so sánh vs chuỗi đó.

- So sánh giữa hai chuỗi PHẢI được thực hiện dưới dạng điểm mã Unicode để so sánh một cách bình đẳng.

Ở một số nơi, thì theo tiêu chuẩn này sử dụng danh sách các chuỗi được phân tách bằng dấu cách. Trong tất cả các trường hợp như vậy, một số ký tư ASCII (0x20) PHẢI được sử dụng làm dấu phân cách.

Ứng dụng

Thế kỉ 21 - kỉ nguyên của khoa học và công nghệ, sự phát triển mạnh như vũ bão của công nghệ số đã đem lại một cuộc sống vô cùng tiện ích cho con người. Trong kỉ nguyên ấy, Việt Nam - 1 trong những đất nước có tốc độ phát triển nhanh nhất thế giới là mảnh đất vô cùng màu mỡ của nền công nghệ số. Đặc biệt, với tính mở của nền công nghệ số, việc bảo mật dữ liệu và thông tin là vô cùng cần thiết.

Chính vì vậy, tiêu chuẩn OpenID Connect 1.0 sẽ góp phần quan trọng để Việt Nam có thể phát triển và mở rộng hệ thống chính phủ điện tử và dịch vụ công. Trên hết, yếu tố bảo mật và toàn vẹn dữ liệu đang là một vấn đề nóng được cả thế giới quan tâm, điều cần thiết hơn cả là việc ứng dụng tiêu chuẩn giúp cho việc bảo vệ giữ liệu của chính phủ điện tử sau này, đồng thời là lý thuyết căn bản cho việc chia sẻ dữ liệu với các bên ở hiện tại và trong tương lai.

Vũ Cao Minh Đức

Tài liệu tham khảo:

  1. Hardt, D., “The OAuth 2.0 Authorization Framework,” RFC 6749, October 2012 (TXT).
  1. Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012 (TXT).
  1. Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” draft-ietf-jose-json-web-signature (work in progress), July 2014 (HTML).
  1. Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” draft-ietf-oauth-json-web-token (work in progress), July 2014 (HTML).
  1. Sakimura, N., Bradley, J., Jones, M., and E. Jay, “OpenID Connect Discovery 1.0,” November 2014.
  1. Hardt, D., cụm Khung ủy quyền OAuth 2.0 , RFC 6749, tháng 10 năm 2012 ( TXT ).
  1. Davis, M., Whistler, K., and M. Dürst, “Unicode Normalization Forms,” Unicode Standard Annex 15, 09 2009.
  1. Raggett, D., Hors, A., and I. Jacobs, “HTML 4.01 Specification,” World Wide Web Consortium Recommendation REC-html401-19991224, December 1999 (HTML).
Go top