OAuth là một giao thức quan trọng trong thế giới kỹ thuật số, đặc biệt trong bảo mật và quản lý truy cập. Cùng tìm hiểu về OAuth 2.1 và OAuth 2.0 nhé!

Trong thời kỳ kỹ thuật đang ngày càng phát triển như hiện nay, việc cho phép các dịch vụ trực tuyến có thể chia sẻ dữ liệu và tương tác với nhau đang trở nên phổ biến và quan trọng hơn. Tuy nhiên, việc này tiềm ẩn nhiều rủi ro làm tiết lộ thông tin cá nhân của chúng ta cho các bên thứ ba. OAuth được sinh ra để giúp chúng ta chia sẻ thông tin một cách an toàn, hiệu quả và tin cậy.

OAuth là một giao thức quan trọng trong thế giới kỹ thuật số, đặc biệt trong lĩnh vực bảo mật và quản lý truy cập. Đối với người dùng internet, chúng ta thường xem nó như một phần của quá trình đăng nhập vào các ứng dụng và dịch vụ trực tuyến hàng ngày. Tuy nhiên, OAuth cũng đóng vai trò quan trọng trong việc đảm bảo an toàn và quản lý quyền truy cập vào thông tin cá nhân của chúng ta.

Nhưng OAuth là gì? Và tại sao cần phải quan tâm tới phiên bản mới là OAuth 2.1? Chúng ta sẽ cùng khám phá và so sánh OAuth 2.1 với phiên bản trước đó - OAuth 2.0 để hiểu rõ hơn về sự khác biệt và cải tiến mà phiên bản mới mang lại. Bắt đầu từ việc tìm hiểu về bản chất của OAuth, chúng ta sẽ cùng nhau đào sâu vào thế giới của bảo mật và truy cập trực tuyến nhé.

1. OAuth là gì?

OAuth (Open Authorization) là một tiêu chuẩn mã nguồn mở cho phép uỷ quyền truy cập, thường được dùng như cách để người dùng cấp quyền cho một trang web, hoặc một ứng dụng có quyền truy cập vào thông tin của họ ở một hệ thống khác mà không cung cấp cho họ thông tin đăng nhập.

Nói cách khác, người dùng có thể cho phép các bên thứ 3 truy cập vào thông tin của họ mà không cần cung cấp thông tin xác thực.

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

2. Các vai trò chính trong OAuth

OAuth có 4 định nghĩa vai trò chính, bao gồm: resource owner, resource server, client, authorization server.

2.1. Resource owner - Chủ sở hữu tài nguyên

Resource owner (chủ sở hữu tài nguyên) là người đang sử dụng hoặc quản lý tài nguyên mà bên thứ ba muốn truy cập. Thông thường, đây là người dùng cuối, và họ có quyền quyết định xem liệu các bên thứ ba có được phép truy cập vào tài nguyên đó hay không.

Trong OAuth, vai trò của resource owner là uỷ quyền cho các ứng dụng khác, thay mặt họ, truy cập vào các tài nguyên mà chính resource owner chỉ định.

2.2. Resource server - Máy chủ tài nguyên

Resource server là nơi lưu trữ các tài nguyên mà resource owner sở hữu. Nó phụ trách xử lý các yêu cầu truy cập từ client, dựa trên quyền truy cập (thường thể hiện qua access token) mà resource owner đã cấp cho client.

2.3. Client

Client là ứng dụng hoặc hệ thống đang yêu cầu được cấp quyền truy cập vào tài nguyên của resource owner.

Để thực hiện điều này, client cần nhận được access token từ resource owner, sau đó sử dụng token này để gửi yêu cầu đến resource server nhằm truy cập vào các tài nguyên mong muốn.

2.4. Authorization server - Máy chủ xác thực

Authorization server có thể được mô tả như là một "bảo vệ" mà thông qua nó, resource owner có thể quản lý và kiểm soát việc ai được quyền truy cập vào tài nguyên mà họ sở hữu. Authorization server xác minh danh tính của resource owner, và sau đó cấp một "chìa khóa" (được gọi là access token) cho client, cho phép họ truy cập vào tài nguyên cụ thể nào đó trong một khoảng thời gian nhất định hoặc cho đến khi resource owner thu hồi quyền truy cập.

Về bản chất, Authorization server đóng vai trò trung gian, đảm bảo rằng mọi giao dịch truy cập đều được xác minh đúng cách, đồng thời giúp bảo vệ thông tin cá nhân và dữ liệu quan trọng từ việc truy cập không được phép hoặc lạm dụng.

3. OAuth hoạt động như thế nào?

3.1. Mô tả sơ lược về OAuth

Trước khi chúng ta đào sâu vào chi tiết, xin lưu ý rằng "authorization", hoặc "uỷ quyền" trong tiếng Việt, là quá trình mà bạn cho phép một bên thứ ba truy cập vào những tài nguyên mà bạn quản lý hoặc sở hữu, nhưng chỉ trong phạm vi mà bạn đã chỉ định.

Để làm được điều này, bạn cần thực hiện việc xác minh danh tính của mình và cấp quyền cho bên thứ ba để họ có thể tiếp cận các tài nguyên bạn đang quản lý. Quá trình này thường đi qua ba bước chính:

1. Xác nhận danh tính: Danh tính của bạn cần phải được đảm bảo và không thể bị sao chép và làm giả.
2. Chấp nhận uỷ quyền: Danh tính của bên thứ ba cũng cần được đảm bảo tuyệt đối, và bên thứ ba này có bằng chứng cho sự uỷ quyền của bạn.
3. Tiếp nhận tài nguyên: Sau khi nhận được thông tin ủy quyền cùng với thông tin danh tính của cả người sở hữu tài nguyên và bên được ủy quyền, bên tiếp nhận có trách nhiệm phải tuân thủ và đáp ứng đúng các yêu cầu đã đặt ra.

Để dễ hình dung hơn, chúng ta hãy liên tưởng OAuth như một lệnh khám xét. Ở đó, chúng ta có ba bên rằng: Toà án, cảnh sát và người bị khám xét.

Khi đó, tờ giấy "lệnh khám xét" là một biểu hiện của danh tính của toà án, cảnh sát, cũng như sự uỷ quyền, ở đó, toà án uỷ quyền cho cảnh sát được phép thực thi lệnh khám xét, và người bị khám xét có nghĩa vụ phải đáp ứng lệnh khám xét đó.

Sau đây, hãy cùng 200Lab tìm hiểu về cụ thể về OAuth nhé!

OAuth hoạt động thông qua một chuỗi các tương tác liên tiếp với nhau giữa bốn thành phần đã được kể trên. Nói một cách ngắn gọn, OAuth thực hiện liên tiếp những trình tự sau:

1. Authorization Request: Là quá trình client yêu cầu resource owner cung cấp và xác thực uỷ quyền (grant) cho mình.
2. Authorization Grant: Resource owner sẽ gửi authorization grant (xác thực uỷ quyền) của mình cho client. Client sẽ dùng thông tin này cho giai đoạn tiếp theo.
3. Access Token Request: Là giai đoạn mà client, từ grant có được của user, yêu cầu authorization server cung cấp cho mình quyền được truy cập vào các thông tin cần thiết.
4. Access Token Response: Authorization server sẽ cung cấp cho client một access token, client sẽ dùng token này để truy cập vào tài nguyên mong muốn.
5. Resource Request: Client sẽ yêu cầu resource owner cung cấp cho mình thông tin mong muốn, điều kiện là client sở hữu access token để xác thực thông tin uỷ quyền của mình.
6. Resource Response: Resource owner sẽ gửi các thông tin đến client, kết thúc quá trình.

Như trên hình vẽ, trong toàn bộ quá trình trên, client đều phải giao tiếp với các thành phần còn lại trong OAuth, bao gồm theo thứ tự: resource owner, authorization server và resource server.

Thực tế, tuỳ thuộc vào kiểu của OAuth, một số bước trong tiến trình sẽ được rút gọn, hoặc thay đổi. Chúng ta sẽ nói rõ hơn ở chương 4.

Phần tiếp theo sẽ mô tả kỹ hơn ba giai đoạn giao tiếp trên.

3.2. Authorization grant request

Authorization Request và authorization grant là bước đầu tiên của quá trình OAuth. Tại bước này, client sẽ gửi request để yêu cầu user gửi thông tin uỷ quyền truy cập, cho phép client tiếp cận đến các tài nguyên mong muốn.

3.2.1. Request information

Trong quá trình này, client sẽ gửi cho resource owner một số thông tin trong url parameters. Thông thường, các thông tin trao đổi bao gồm:

• Client ID: Mã định danh của client, đã được client đăng ký trước với authorization server. Mỗi client sẽ có mã ID duy nhất, dùng để xác định xem client nào đang yêu cầu quyền truy cập.
• Redirect Url: Là một url mà Authorization server sẽ điều hướng resource owner đến trong trường hợp chấp nhận hoặc từ chối cấp quyền cho client. Cũng giống với client id, redirect url cũng cần phải đăng ký trước với authorization server, và cũng được client cung cấp khi client đăng ký với authorization server.
• Response Type: Chỉ định loại cấp phép mà client yêu cầu. Thông thường, nó sẽ có giá trị là code để cấp quyền thông qua mã hoặc token để cấp quyền ngầm định.
• Space: Là danh sách những thông tin mà client yêu cầu được resource owner cung cấp. Một số thông tin mà client thường yêu cầu bao gồm email, mã định danh của resource owner, số điện thoại, vv.
• State: Là một tham số không bắt buộc, được client gửi cho resource owner trong quá trình cấp quyền, dùng để duy trì trạng thái trao đổi giữa hai bên. State có khả năng phòng chống cuộc tấn công CSRF (cross-site request forgery).

3.2.2. Process

Tiến tình thực hiện Authorization Request bao gồm

• Khởi tạo authorization url: Client sẽ khởi tạo một url, với các tham số đã nêu ở trên, để điều hướng resource owner truy cập vào url đó.
• Resource owner đồng ý cấp quyền: Tại url trên, resource owner có thể sẽ phải đăng nhập để authorization server biết được thông tin của resource owner, trong trường hợp chưa đăng nhập. Sau đó, authorization server sẽ hiển thị các thông tin mà client muốn truy cập vào.
  Resource owner có thể đồng ý hoặc từ chối yêu cầu cấp quyền của client.
• Phản hồi uỷ quyền: Tại bước này, nếu resource owner đồng ý cấp quyền, authorization server sẽ chuyển resource owner về application.

3.2.3. Response information

Kết thúc bước này, client đã có được Authorization Grant, dùng để tiếp nối bước thứ hai.

3.3. Access token request

Tại bước này, khi đã có thông tin Authorization Grant (dưới sự cho phép của resource owner), client sẽ dùng thông tin này để đổi lấy thông tin access token.

3.3.1. Request information

Trong quá trình này, client sẽ sử dụng duy nhất một thông tin, là kết quả của tiến trình trước, để trao đổi với authorization server, yêu cầu authorization server cung cấp cho mình quyền được truy cập vào tài nguyên mong muốn.

• Authorization grant: thông tin uỷ quyền, là một chứng nhận đại diện cho resource owner, và được sử dụng để xác thực client đã được resource owner uỷ quyền truy cập vào các tài nguyên mong muốn.

3.3.2. Process

Ở giai đoạn này, client sẽ gửi authorization grant của mình cho authorization server thông qua https POST method (có trường hợp gửi bằng method GET, sẽ bàn kỹ hơn ở chương 4).

3.3.3. Response information

Sau khi quá trình Access token request kết thúc, client sẽ có những thông tin sau

• Access token: Là token được sử dụng để truy cập vào tài nguyên. Client sẽ gửi cho resource server để lấy về thông tin mong muốn. Access token sẽ có thời gian sử dụng giới hạn, được thể hiện qua thông tin expired đi kèm.
• Refresh token: Khi access token hết hạn, client có thể sử dụng refresh token để làm mới. Refresh token có thời gian tồn tại lâu hơn so với access token, thời gian này tuỳ thuộc vào server. Sau khi hết thời gian của refresh token, client sẽ phải thực hiện lại các quá trình trên để có được access và refresh token mới.

3.4. Resource request

Bước cuối cùng để client có thể truy cập được vào các thông tin cần thiết. Client sẽ sử dụng access token để truy cập vào tài nguyên mà client mong muốn.

3.4.1. Request information

Để có thể xác định được client là ai và resource chính xác, trong quá trình trao đổi, client sẽ cần phải gửi một số thông tin sau:

• Client Identifier: Dùng để định danh client. Thông tin này đã được đề cập ở bước authorization grant.
• Access Token: Token dùng để truy cập vào resource. Trong đa số trường hợp, access token sẽ được gửi theo tiêu chuẩn JWT.

3.4.2. Process

Khi resource server nhận được yêu cầu truy cập resource của client, resource server sẽ cần kiểm tra ba thông tin chính. Ba thông tin đó bao gồm:

• Kiểm tra Access Token: Resource server cần kiểm tra tính chính xác của token để xem nó có hợp lệ hay không.
• Xác định resource: Resource server cần xác định chính xác client có thể truy cập vào các thông tin nào, tránh trường hợp client lấy thừa hoặc thiếu thông tin.
• Truy xuất và phản hồi: Resource server có trách nhiệm lấy ra các thông tin mà client yêu cầu, và gửi cho client dưới dạng HTTP response

3.4.3. Response information

Sau khi nhận phản hồi của resource server, client sẽ có được thông tin mong muốn nếu thành công. Client sẽ sử dụng thông tin này vào các mục đích mà nó đã thoả thuận với resource owner ở bước đầu tiên

4. Một số kiểu OAuth thường gặp

4.1. Authorization Code Grant

Tại kiểu authorization grant này, khi resource owner đồng ý uỷ thác cho client, authorization server sẽ gửi cho client một mã authorization code thông qua redirect url. Client sẽ dùng thông tin này để đổi lấy access token.

Kiểu OAuth này cần sử dụng toàn bộ quá trình ở chương 3 để hoàn thành truy cập vào tài nguyên.

4.2. Implicit Grant

Implicit grant được sử dụng ở đa phần các website hiện nay, tuy nhiên, đang được thay thế dần sang PKCE do lo ngại về bảo mật.

Về cách thức hoạt động, khi resource owner đồng ý, authorization server sẽ gửi trực tiếp cho client một access token mà loại bỏ luôn giai đoạn xác thực uỷ quyền.

Mất đi giai đoạn xác thực uỷ quyền tiềm ẩn nhiều rủi ro về mạo danh resource owner để tiếp cận tài nguyên trái phép, do đó, tính bảo mật không được như kiểu authorization code grant.

4.3. Resource Owner Password Credentials Grant

Resource Owner Password Credentials Grant (ROPC) được sử dụng ở client mà được mọi người thực sự tin tưởng, vì loại này yêu cầu resource owner cung cấp tài khoản của họ cho client.

Khi resource owner cung cấp thông tin đăng nhập (bao gồm username và password) cho client, client sẽ tổng hợp thông tin và gửi cho authorization server. Sau đó, authorization server sẽ gửi access token cho client.

Kiểu truy cập này có khác biệt lớn ở giai đoạn authorization grant request và access token request. Trong đó, thay vì để resource owner đồng ý uỷ quyền, client yêu cầu resource owner cung cấp thông tin đăng nhập cho client.

Ngoài ra, thay vì lấy authorization grant, client sẽ yêu cầu trực tiếp authorization server cung cấp access token, từ thông tin đăng nhập của resource owner.

Do đó, kiểu đăng nhập này chỉ được sử dụng ở client thực sự được các bên tin tưởng.

4.4. Client Credentials Grant

Ở kiểu này, client và resource owner là một. Có nghĩa là client đang yêu cầu truy cập thông tin của chính nó. Vì thế, client sẽ không cần sự uỷ quyền của ai cả, nên có thể giản lược giai đoạn authorization grant request.

Kiểu OAuth này là server to server communication, đa phần được sử dụng trong giao tiếp giữa các service trong microservice.

4.5. Proof Key for Code Exchange (PKCE)

Proof Key for Code Exchange (PKCE) là kiểu OAuth được khuyên dùng cho các đa số các client. Điểm khác biệt giữa PKCE và các kiểu khác là để tránh việc resource owner cấp uỷ quyền cho sai client.

Để làm được việc đó, khi ở bước authorization grant request, client sẽ tự tạo thêm một mã code verifier, và hash nó lại, gửi cho resource owner. Sau đó, resource owner sẽ gửi mã hash này cho authorization server.

Ở bước access token request, khi client gửi authorization grant cho authorization server, client sẽ buộc phải gửi thêm code verifier ở bản trước khi hash. Authorization server sẽ hash code verifier của client gửi và so sánh với bản hash mà resource owner gửi đến. Nếu đúng, authorization server mới gửi cho client thông tin access token.

5. Sự khác biệt giữa OAuth 2.0 và OAuth 2.1 là gì?

OAuth 2.1 được phát triển như một bước tiến vững chắc từ phiên bản 2.0, giới thiệu nhiều cải tiến đáng kể về mặt bảo mật, nhằm giải quyết các rủi ro và hạn chế đã xuất hiện trong phiên bản trước. Một số vấn đề bao gồm thời gian tồn tại của refresh token, tiêu chuẩn hoá giao thức cho các public client, loại bỏ các kiểu OAuth không còn phù hợp cũng đã được cân nhắc và giải quyết.

Tính đến thời điểm hiện tại, OAuth 2.1 vẫn đang trong quá trình được nghiên cứu và định rõ hơn, chưa chính thức được công bố dưới hình thức một RFC đầy đủ, và đang là đề tài của nhiều cuộc thảo luận sôi nổi.

Theo đó, một số thay đổi lớn của OAuth 2.1 bao gồm:

1. Loại bỏ Implicit Grant: Implicit grant sẽ bị loại bỏ khỏi phiên bản 2.1, thay thế bằng PKCE.
2. Khuyến nghị sử dụng Proof Key for Code Exchange: Tại phiên bản 2.1, PKCE trở thành tiêu chuẩn bắt buộc có các client công cộng.
3. Không khuyến khích Resource Owner Password Credentials Grant: Các client có độ tin cậy cao mới khuyến nghị sử dụng cách thức này.
4. Xác thực client: Khuyến khích sử dụng HTTP basic authentication để tránh rủi ro thông tin clientId bị đánh cắp.
5. Xử lý refresh token: Ở phiên bản 2.0, không có điều luật cụ thể nào cho refresh token. Tại phiên bản 2.1, refresh token cần tuân thủ nhiều điều luật rằng buộc. Hiện điều khoản của refresh token vẫn đang trong quá trình hoàn thiện.
6. Redirect URL: Nhằm ngăn chặn việc tấn công chuyển hướng (redirection attacking), redirect URL cần tuần thủ một số điều luật cụ thể.

Nhìn chung, OAuth 2.1 hướng tới việc tinh giản và nâng cao mức độ bảo mật của OAuth 2.0, bằng việc tiếp thu và áp dụng những kinh nghiệm quý giá tích luỹ từ khi phiên bản gốc được ra mắt.

OAuth 2.1 khuyến khích việc áp dụng những phương thức và thủ tục bảo mật hơn, giúp hệ thống có khả năng chống chịu và phòng ngừa hiệu quả hơn đối với nhiều hình thức tấn công và lạm dụng khác nhau.

6. Kết luận

Trong bối cảnh web hiện đại, OAuth đóng vai trò là rất quan trọng cho phép ủy quyền an toàn và hiệu quả. Bằng cách liên tục phát triển để giải quyết các mối lo ngại về bảo mật đang nổi lên, nó cung cấp một tiêu chuẩn mạnh mẽ hơn giúp bảo vệ dữ liệu người dùng đồng thời tạo điều kiện tích hợp liền mạch giữa các ứng dụng.

Đối với người dùng, sự tiến bộ của OAuth 2.1 đồng nghĩa với việc bảo vệ thông tin cá nhân và quyền riêng tư của họ một cách tốt hơn khi sử dụng các ứng dụng và dịch vụ trực tuyến. Đối với nhà phát triển, việc áp dụng và thích nghi với các thay đổi của OAuth 2.1 là cần thiết để xây dựng ứng dụng an toàn và đáng tin cậy, mang lại trải nghiệm tích cực cho người dùng.

Dù là OAuth 2.0 hay OAuth 2.1, việc hiểu và tận dụng tối đa giao thức này sẽ mang lại lợi ích lớn cho môi trường kỹ thuật số ngày càng phát triển và đa dạng.

Tài liệu tham khảo:

1. What is OAuth 2
2. An introduction to OAuth 2
3. OAuth 2
4. OAuth wiki
5. RFC OAuth 2.1 (draft)
6. RFC OAuth 2.0

Giờ thì bạn đã hiểu OAuth là gì rồi đúng không nào? Hãy thường xuyên theo dõi các bài viết hay về Lập Trình & Dữ Liệu trên 200Lab Blog nhé. Cũng đừng bỏ qua những khoá học Lập Trình tuyệt vời trên 200Lab nè.

Một vài bài viết mới bạn sẽ thích:

Backend Developer Là Gì? Lộ Trình Trở Thành Backend Developer

Database là gì? Có những loại database nào và ứng dụng

WebSocket là gì? Lý do sử dụng WebSocket

SocketIO là gì? Top 10 lý do nên chọn Socket.IO

Giải pháp scale WebSocket với Socket.IO

Git là gì? Tổng quan về Git cơ bản cho lập trình viên

Postman là gì? Cách dùng Postman trong API testing

Apache Kafka: Quản lý Schema & Avro Serialization trong hệ thống