Giao thức OAuth

Hình 2 .6 Sử dụng Yadis để xác định địa chỉ của Identity Provider

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.

2.3.2 Tich hợp OAuth với CardSpace

Từ giao thức OAuth đã tìm hiểu ở mục 2.3.1 thì việc tích hợp OAuth với CardSpace được thể hiện như trong Hình 2.11 và gồm các bước chính sau [15]:

1. UA → RP: Người dùng yêu cầu một trang đăng nhập từ RP

2. RP → UA: Một trang đăng nhập được RP trả lại. Trang đăng nhập này có chứa những thẻ cho phép gọi CardSpace và những trường và chính sách bảo mật của RP cũng được nhúng vào trong trang đăng nhập của RP trả về.

3. Extension → UA: Chương trình tích hợp sẽ thực hiện các bước sau:

1. Extension kiểm tra trang đăng nhập mà RP trả về cho UA để phát hiện xem RP có hỗ trợ CardSpace hay không. Nếu RP có hỗ tr thì chương trình tiếp tục xử lý còn nếu RP không hỗ trợ thì chương trình sẽ dừng lại. 2. Extension xem xét chính sách của RP để kiểm tra xem việc sử dụng thẻ

cá nhân có được chấp nhận hay không? Nếu có thì tiếp tục xử lý và nếu không thì cho CardSpace hoạt động bình thường.

3. Extension giữ lại các trường và những khai báo mà RP yêu cầu.

4. Extension khám phá ra giao thức mà RP sử dụng để giao tiếp là HTTP hoặc HTTPS.

5. Nếu HTTP được sử dụng , Extension sẽ thay đổi chính sách của RP để chính sách này bao gồm cả những trường được sử dụng trong thể OAuth (OAuthCard). Ví dụ, nếu URL của SP được lưu trữ trong trường “web page” của OAuthCard, thì Extension phải đảm bảo rằng chính sách bảo mật của RP bao gồm có thêm trường “web page”. Việc bổ sung những kiểu trường này cho RP để đảm bảo rằng những mã được cung cấp bởi SIIP sẽ chứa giá trị của nhừng trường này, những giá trị này sẽ được Extension sử dụng khi cần thiết.

4. Người dùng → UA: Trang đăng nhập của RP sẽ đưa ra gợi ý cho người dùng lựa chọn CardSpace. Việc lựa chọn này sẽ kích hoạt Selector nếu như thỏa mãn được các chính sách của RP.

Giao thức tích hợp giữa OpenID và CardSpace