OAuth2: Giải pháp ủy quyền truy cập an toàn và hiệu quả cho ứng dụng

Chắc hẳn bạn đã từng nghe đến OAuth, một phương thức xác thực cho phép ứng dụng bên thứ ba truy cập tài nguyên của bạn trên một dịch vụ khác. OAuth, viết tắt của Open Authorization, bao gồm:

  • Authentication (Xác thực): Xác minh danh tính người dùng.
  • Authorization (Ủy quyền): Cấp quyền truy cập vào tài nguyên mà người dùng sở hữu.

OAuth2 là phiên bản nâng cấp của OAuth 1.0, một giao thức ủy quyền cho phép các ứng dụng chia sẻ tài nguyên mà không cần thông tin đăng nhập (username/password) truyền thống. Điều này giúp giảm thiểu rủi ro khi phải nhập thông tin cá nhân ở nhiều nơi hoặc quản lý quá nhiều tài khoản và mật khẩu.

Các vai trò trong OAuth2

OAuth2 định nghĩa bốn vai trò chính:

  • Resource Owner (Chủ sở hữu tài nguyên): Người dùng có quyền cấp quyền truy cập vào tài nguyên của họ.
  • Resource Server (Máy chủ tài nguyên): Nơi lưu trữ tài nguyên và xử lý yêu cầu truy cập.
  • Client (Ứng dụng khách): Ứng dụng bên thứ ba muốn truy cập tài nguyên được chia sẻ với sự ủy quyền của người dùng.
  • Authorization Server (Máy chủ ủy quyền): Xác thực người dùng, kiểm tra thông tin và cấp quyền truy cập bằng cách tạo ra access token. Đôi khi, máy chủ ủy quyền cũng chính là máy chủ tài nguyên.

Token: Chìa khóa truy cập tài nguyên

Token là một chuỗi mã ngẫu nhiên do Authorization Server tạo ra khi nhận được yêu cầu từ Client. Có hai loại token chính:

  • Access token
  • Refresh token

1. Access token

Access token là mã xác thực quyền truy cập, cho phép ứng dụng bên thứ ba truy cập dữ liệu người dùng trong phạm vi được cho phép. Client gửi token này như một tham số trong header của mỗi request khi cần truy cập tài nguyên trên Resource server.

Việc để lộ access token tương đương với việc lộ mật khẩu, vì nó có thể bị lợi dụng để truy cập tài nguyên được bảo vệ. Do đó, access token có thời gian sử dụng giới hạn (ví dụ: 2 giờ, 2 tháng) tùy thuộc vào yêu cầu bảo mật. Access token thường chỉ được sử dụng một lần. Khi hết hiệu lực, Client phải yêu cầu Authorization server cấp một access token mới.

2. Refresh token

Refresh token cũng được Authorization server tạo ra cùng lúc với access token, nhưng có chức năng khác. Refresh token được sử dụng để lấy một access token mới khi access token hết hạn. Vì vậy, refresh token có thời gian hiệu lực dài hơn access token (ví dụ: access token có hiệu lực 2 giờ, refresh token có thể lên đến 10 giờ).

Refresh token cho phép Client lấy lại access token mà không cần người dùng xác thực lại. Nếu người dùng đăng xuất, refresh token cũng sẽ bị xóa.

Scope: Phạm vi truy cập

Scope là một tham số được định nghĩa trên Authorization server, dùng để giới hạn quyền và phạm vi tài nguyên mà access token được phép truy cập. Client xác định scope khi yêu cầu tạo access token.

Phân loại các luồng OAuth2

OAuth2 có bốn loại cấp quyền chính:

  • Authorization Code
  • Resource Owner Password Credentials
  • Implicit
  • Client Credentials

Trước khi đi vào chi tiết, hãy cùng tìm hiểu hai thuật ngữ quan trọng:

  • Client Identifier (Client ID): Chuỗi ký tự định danh ứng dụng.
  • Client Secret: Chuỗi ký tự dùng để xác thực Client khi ứng dụng yêu cầu truy cập thông tin tài khoản người dùng. Chuỗi này được giữ bí mật giữa Client và Authorization Server.

Bạn có thể hiểu Client ID như username và Client Secret như password của Client đối với Authorization Server.

1. Authorization Code

Đây là loại phổ biến nhất, thường được sử dụng khi Client là một máy chủ web (Server-side Application). Nó cho phép lấy về access token dài hạn (long-lived) và có thể lấy access token mới thông qua refresh token (nếu có).

Ví dụ:

  • Resource Owner: Bạn
  • Resource Server: Máy chủ Google
  • Client: Bất kỳ website nào
  • Authorization Server: Máy chủ Google

Cách hoạt động:

  1. Người dùng nhấp vào nút đăng nhập trên ứng dụng web.
  2. Ứng dụng web chuyển hướng người dùng đến Authorization server để bắt đầu quá trình nhận authorization code.
  3. Người dùng được chuyển đến trang đăng nhập.
  4. Người dùng nhập thông tin đăng nhập (ví dụ: username và password).
  5. Authorization server xác thực thông tin đăng nhập và chuyển hướng người dùng đến “redirect URI” của ứng dụng (nơi ứng dụng nhận thông tin trả về từ Authorization server) kèm theo một đoạn “authorization code”.
  6. Ứng dụng (Client) gửi request đến Authorization server, bao gồm Client ID, Client secret (đã khai báo trước đó) cùng với authorization code vừa nhận.
  7. Authorization server xác minh thông tin mà Client vừa gửi.
  8. Nếu thông tin hợp lệ, Authorization server trả về access token cùng với refresh token (nếu có).
  9. Ứng dụng gửi request tới Resource server kèm theo access token vừa nhận.
  10. Resource server kiểm tra access token, nếu hợp lệ thì trả về tài nguyên tương ứng mà access token cho phép truy cập.

2. Resource Owner Password Credentials

Loại này cho phép ứng dụng bên thứ ba lấy token bằng cách sử dụng thông tin tài khoản của người dùng. Tuy nhiên, nó được đánh giá là kém an toàn hơn Authorization Code và chỉ nên dùng ở một số trang web lớn hoặc khi bạn thực sự tin tưởng ứng dụng, vì nó trực tiếp xử lý thông tin tài khoản người dùng.

Cách hoạt động:

  1. Người dùng nhập thông tin đăng nhập (ví dụ: username, password) vào form trên ứng dụng (Client).
  2. Ứng dụng (Client) gửi thông tin đăng nhập cùng Client ID, Client secret lên Authorization server.
  3. Authorization server kiểm tra thông tin đăng nhập của người dùng và định danh mà Client gửi lên. Nếu tất cả hợp lệ, nó sẽ trả về access token cùng với refresh token (nếu có).
  4. Ứng dụng sử dụng access token vừa nhận được để truy cập Resource server.

3. Implicit

Loại này thường được sử dụng cho các ứng dụng mobile hoặc ứng dụng chạy trên trình duyệt web. Trong loại này, access token được gửi trực tiếp đến ứng dụng thông qua URI trên trình duyệt. Phương thức này hoàn toàn tin tưởng vào URI đã đăng ký trước đó mà không cần bất kỳ phương thức xác thực nào đối với ứng dụng (Client).

Loại xác thực này không hỗ trợ refresh token.

Cách hoạt động:

  1. Người dùng nhấp vào đăng nhập trên ứng dụng web.
  2. Trình duyệt chuyển hướng người dùng đến Authorization server.
  3. Nếu người dùng cho phép truy cập, Authorization server chuyển hướng về lại ứng dụng với access token được gửi trong URI. Ví dụ: https://example.com/oauth-callback#access_token=MNBD2DAasd99
  4. Ứng dụng (Client) có thể truy vấn Resource server thông qua access token vừa lấy được.

4. Client Credentials

Loại ủy quyền này phục vụ cho mục đích giúp Client xác thực chính nó với Authorization server để truy cập vào chính những tài nguyên mà nó đang nắm giữ.

Tương tự như loại Implicit, Client Credentials không hỗ trợ refresh token.

Cách hoạt động:

  1. Client gửi Client ID và Client secret của chính mình đến Authorization server.
  2. Authorization server xác thực thông tin được gửi đến. Nếu xác nhận đó là Client, nó sẽ gửi lại access token.
  3. Client dùng access token đó truy cập đến Resource server để lấy tài nguyên.

Kết luận

OAuth2 là một giao thức mạnh mẽ và linh hoạt, cung cấp nhiều phương thức ủy quyền khác nhau để phù hợp với các loại ứng dụng và yêu cầu bảo mật khác nhau. Việc hiểu rõ các khái niệm và luồng hoạt động của OAuth2 là rất quan trọng để xây dựng các ứng dụng an toàn và bảo mật.

Tham khảo