Giao thức OAuth

Trước khi bắt đầu tìm hiểu chi tiết giao thức OAuth, RP và IdP thống nhất sử dụng chung một cặp khóa để giao tiếp với nhau là: “consumer key” và “secret key” . Để có được cặp khóa này thì RP phải đăng ký với IdP. Trong đó:

 Consumer key: IdP sử dụng “consumer key” để xác định duy nhất một RP. Mỗi RP sẽ có một “consumer key” khác nhau.

 Secret key: Được RP và IdP sử dụng để tạo ra chữ ký mỗi khi có yêu cầu gửi từ RP tới IdP.

Chi tiết giao thức OAuth được thể hiện trong Hình 2.10 [14].

1. RP → IdP: RP gửi một yêu cầu tới IdP để lấy thẻ yêu cầu (request token). 2. IdP → RP: IdP trả lại cho RP một thẻ truy cập gồm: “token secret” và “token

key”. Thẻ yêu cầu này không có quy ền truy cập vào dữ liệu của người dùng trên IdP.

3. RP → UA → IdP: RP sử dụng thẻ yêu cầu đ ể chuyển hướng người dùng tới IdP. Mục đích của bước này là RP muốn sử dụng thẻ yêu cầu đ ể xin quyền truy cập vào dữ liệu người dùng trên IdP.

4. IdP → Người dùng: Tại đây, IdP sẽ xác thực người dùng và đưa ra gợi ý về mục đích của RP xin quyền truy cập vào dữ liệu người dùng trên IdP.

5. Người dùng → IdP: Người dùng đồng ý hay từ chối cho RP truy cập vào dữ liệu của người dùng trên IdP.

6. IdP → RP: IdP trả về cho RP một mã oauth_verifier để thông báo cho RP biết là người dùng đã xác thực với IdP và đã ủy quyền cho RP truy cập vào dữ liệu của người dùng trên IdP.

7. RP → IdP: RP gửi lại oauth_verifier và thẻ yêu cầu lên IdP đ ể trao đổi lấy thẻ truy cập .

Hình 2.10: Giao thức OAuth

8. IdP → RP: Sau khi IdP kiểm tra tính hợp lệ của các giá trị thẻ yêu cầu và oauth_verifier. Nếu hợp lệ thì IdP sẽ trả về thẻ truy cập (access token) cho RP. Khi RP nhận được thẻ truy cập từ phía IdP thì RP có thể sử dụng thẻ truy cập này để truy cập dữ liệu của người dùng trên IdP.

Quá trình lấy thẻ yêu cầu của RP sẽ được mô tả chi tiết trong mục 2.3.1.1 và việc RP sử dụng thẻ yêu cầu để trao đổi lấy thẻ truy cập từ IdP sẽ được mô tả chi tiết trong mục 2.3.1.3.

2.3.1.1 RP lấy thẻ yêu cầu từ IdP

RP sẽ nhận được một thể yêu cầu từ IdP bằng việc gửi một yêu cầu tới IdP . Mục đích của thẻ yêu cầu là:

 Được RP sử dụng để yêu cầu và nhận sự ủy quyền từ phía người dùng.

 Sau khi được người dùng chấp thuận thì thẻ yêu cầu này được sử dụng để lấy một thẻ truy cập từ IdP.

Quá trình RP nhận được một thẻ yêu cầu từ IdP được diễn ra như sau:

RP yêu cầu một thẻ yêu cầu: Để nhận được một thẻ yêu cầu, RP sẽ gửi một yêu cầu HTTP tới URL “request token” của IdP. Tham số của của yêu cầu HTTP là:

 oauth_consumer_key: Là một khóa mà RP đăng ký với IdP.

IdP

Relying Party User Agent

Get sp.com/oauth/request_token IdP trả về thẻ yêu cầu

RP chuyển hướng user tới IdP bằng cách sử dụng thẻ yêu cầu Xác thực user Yêu cầu user

ủy quyền IdP trả về mã oauth_verifier cho RP

RP gửi oauth_verifier và thẻ yêu cầu tới IdP để lấy thẻ truy cập IdP trả về thẻ truy cập cho RP

 oauth_signature_method: Là phương pháp tạo chữ ký của RP , được sử dụng để ký toàn bộ yêu cầu HTTP mà RP gửi tới IdP.

 oauth_signature: Là chữ ký . Chữ ký này được tạo ra khi RP sử dụng phương pháp ký để ký toàn bộ yêu cầu HTTP.

 oauth_timestamp và oauth _nonce: Sử dụng để đảm bảo là yêu cầu HTTP và chữ ký được tạo ra là duy nhất và tồn tại trong một thời gian nhất định . oauth_nonce là một giá trị không trùng lặp cho tất cả các yêu cầu . Một oauth_nonce là một chuỗi ngẫu nhiên , được sinh ra không trùng lặp cho mỗi yêu cầu, oauth_nonce cho phép IdP kiểm tra rằng yêu cầu chưa từng đ ược tạo ra trước đó và tránh được các cuộc tấn công từ các kênh thiếu an toàn.

IdP trả lại một thẻ yêu cầu: IdP xác minh chữ ký và khóa mà RP gửi tới . Nếu thành công thì IdP sẽ tạo ra một thẻ yêu cầu và trả về cho RP. IdP sẽ phải đảm bảo chắc chắn rằng thẻ yêu cầu này không được sử dụng trao đổi để lấy thẻ truy cập cho tới khi được sự ủy quyền truy cập của người dùng.

HTTP trả lại kết quả cho RP gồm các tham số sau:

 oauth_token: Là “request roken”.

 oauth_token_secret: Là “token secret”.

2.3.1.2 Nhận sự ủy quyền từ người dùng

RP không thể sử dụng thẻ yêu cầu để trao đổi thẻ truy cập với IdP cho tới khi nó được ủy quyền bởi người dùng . Để nhận được sự ủy quyền của người dùng cần thực hiện những bước sau:

RP chuyển hướng xác thực người dùng tới IdP : Để RP có thể dùng thẻ yêu cầu để lấy thẻ truy cập thì RP phải nhận được sự chấp thuận của người dùng bằng cách chuyển hướng người dùng tới IdP . RP khởi tạo một yêu cầu HTTP GET tới URL xác thực người dùng của IdP với các tham số sau:

 oauth_token: Là “request token” nhận được ở mục 2.3.1.1

Khi URL đã được xây dựng xong thì RP chuyển hướng người dùng đến URL đó thông qua trình duyệt web của của người dùng.

IdP xác thực và nhận sự ủy quyền của người dùng: IdP xác minh danh tính và yêu cầu sự đồng ý của người dùng. OAuth không chỉ rõ làm thế nào mà IdP có thể xác minh được người dùng . Tuy nhiên, quá trình xác thực người dùng được thực hiện qua các bước bắt buộc sau:

 Bước 1: Đầu tiên, IdP xác minh danh tính của người dùng trước , sau đó mới đến yêu cầu sự đồng ý của người dùng. IdP yêu cầu người dùng đăng nhập nếu người dùng chưa đăng nhập.

 Bước 2: Sau khi IdP xác minh người dùng là hợp lệ thì sẽ đưa ra cho ngườ i dùng biết những thông tin về RP.

 Bước 3: Người dùng có thể đồng ý hoặc từ chối cấp quyền cho RP truy cập vào tài nguyên riêng tư của người dùng trên IdP.

IdP chuyển hướng người dùng quay lại RP:

Sau khi xác thực người dùng tại IdP và cấp quyền truy cập cho RP . Lúc này, thẻ yêu cầu đã được ủy quyền của người dùng và được sử dụng để trao đổi lấy một thẻ truy cập. Nếu người dùng từ chối quyền truy cập thì RP sẽ thông báo thẻ yêu cầu này đã được hủy bỏ.

2.3.1.3 Nhận một thẻ truy cập

RP sẽ dùng thẻ yêu cầu để trao đổi lấy thẻ truy cập. Quá trình trao đổi được diễn ra qua các bước sau:

RP yêu cầu một thẻ truy cập (access token):

Để yêu cầu một thẻ truy cập , RP tạo một yêu cầu HTTP gửi tới URL “access token” của IdP. Một yêu HTTP bao gồm các tham số sau:

 oauth_consumer_key: Là khóa mà RP đăng ký với IdP.

 oauth_token: Là thẻ yêu cầu nhận được phần 2.3.1.1.

 oauth_signature_method: Là phương pháp tạo chữ ký của RP , được sử dụng để ký toàn bộ yêu cầu HTTP mà RP gửi tới IdP.

 oauth_signature: Là chữ ký . Chữ ký này được tạo ra khi RP sử dụng phương pháp ký để ký toàn bộ URL yêu cầu . Mục đích của việc ký trên URL yêu cầu là để ngăn chặn các thành phần không được xác thực có sử dụng khóa của RP và thẻ yêu cầu khi tạo ra các yêu cầu token và yêu cầu tài nguyên.

 oauth_timestamp và oauth _nonce: Sử dụng để đảm bảo là yêu cầu HTTP và chữ ký được tạo ra là duy nhất và tồn tại trong một thời gian nhất định . oauth_nonce là một giá trị không trùng lặp cho tất cả các yêu cầu . Một oauth_nonce là một chuỗi ngẫu nhiên , được sinh ra không trùng lặp cho mỗi yêu cầu, oauth_nonce cho phép IdP kiểm tra rằng yêu cầu chưa từng được t ạo ra trước đó và tránh được các cuộc tấn công từ các kênh thiếu an toàn.

IdP cấp một thẻ truy cập cho RP

IdP xác minh chữ ký và khóa mà RP gửi tới . Nếu thành công thì IdP sẽ tạo ra một thẻ truy cập (access token) và trả về cho RP. Thẻ truy cập sẽ được RP lưu trữ và được sử dụng để ký các yêu HTTP lấy tài nguyên của người dùng . Sự trả lại của IdP gồm các tham số sau:

 oauth_token: Là “access token” mà IdP tạo ra.

 oauth_token_secret: Là “token secret” mà IdP tạo ra . “Token secret” này sẽ gắn liền và duy nhất với “access token”.

2.3.1.4 Truy cập nguồn tài nguyên được bảo vệ

Sau khi nhận thẻ truy cập , thì RP có thể truy cập tài nguyên được bảo vệ của người dùng. Yêu cầu HTTP để lấy tài nguyên phải được ký và gồm các tham số sau:

 oauth_consumer_key: Là khóa mà RP đăng ký với IdP.

 oauth_signature_method: Là phương pháp tạo chữ ký của RP , được sử dụng để ký toàn bộ yêu cầu HTTP mà RP gửi tới IdP.

 oauth_signature: Là chữ ký . Chữ ký này được tạo ra khi RP sử dụng phương pháp ký để ký toàn bộ URL yêu cầu . Mục đích của việc ký trên URL yêu cầu là để ngăn chặn các thành phần không được xác thực có sử dụng khóa của RP và thẻ truy cập khi tạo ra các yêu cầu token và yêu cầu tài nguyên.

 oauth_timestamp và oauth _nonce: Sử dụng để đảm bảo là yêu cầu HTTP và chữ ký được tạo ra là duy nhất và tồn tại trong một thời gian nhất định . oauth_nonce là mộ t giá trị không trùng lặp cho tất cả các yêu cầu . Một oauth_nonce là một chuỗi ngẫu nhiên , được sinh ra không trùng lặp cho mỗi yêu cầu, oauth_nonce cho phép IdP kiểm tra rằng yêu cầu chưa từng được tạo ra trước đó và tránh được các cuộc tấn công từ các kênh thiếu an toàn.

Tích hợp OpenID với CardSpace

Tích hợp OpenID với CardSpace