Chắc hẳn một trong số các bạn đã và đang từng nghe qua khái niệm OAuth trước đó. Về cơ bản, OAuth là một phương thức xác thực giúp một ứng dụng bên thứ 3 có thể được ủy quyền bởi người dùng để làm truy cập đến tài nguyên người dùng nằm trên một dịch vụ khác. OAuth là từ ghép của O (Open) và Auth tượng trưng cho:

Bạn Đang Xem: Tìm hiểu đôi chút về OAuth2

• Authentication: xác thực người dùng.
• Authorization: cấp quyền truy cập đến tài nguyên mà người dùng hiện vẫn đang nắm giữ.

OAuth2 là bản nâng cấp của OAuth1.0, là một giao thức chứng thực được cho phép các ứng dụng san sớt một phần tài nguyên với nhau mà không cần xác thực qua username và password như cách truyền thống từ đó giúp hạn chế được những phiền toái khi phải nhập username, password ở quá nhiều nơi hoặc đăng ký quá nhiều tài khoản mật khẩu mà tất cả chúng ta không thể nào nhớ hết.

Trong OAuth2 khái niệm 4 vai trò:

• Resource owner: là những người dân dùng có khả năng cấp quyền truy cập, chủ sở hữu của tài nguyên mà ứng dụng muốn lấy.
• Resource server: nơi lưu trữ các tài nguyên, có khả năng xử lý yêu cầu truy cập tới những tài nguyên được bảo vệ.
• Client: là những ứng dụng bên thứ 3 muốn truy cập vào phần tài nguyên được san sớt với tư cách của người sở hữu (resource owner) và tất nhiên trước lúc truy cập ứng dụng cần được sự ủy quyền của user.
• Authorization server: làm nhiệm vụ xác thực, kiểm tra thông tin mà user gửi tới từ đó cấp quyền truy cập cho ứng dụng bằng việc sinh ra các đoạn mã access token. Thỉnh thoảng authorization server cũng đấy là resource server.

Token là một đoạn mã được sinh ra tình cờ bởi Authorization server khi có yêu cầu được gửi tới từ Client.

Có 2 loại token:

• Access token
• Refresh token

1.Access token

Là một đoạn mã dùng để làm xác thực quyền truy cập, được cho phép ứng dụng bên thứ 3 có thể truy cập vào những tài liệu của người dùng trong một phạm vi nhất định mà nó được cho phép. Token này được gửi bởi Client như một thông số được truyền vào hreader trong mỗi request khi cần truy cập đến tài nguyên trong Resource server.

Nếu để lộ mất access token thì cũng sẽ có thể coi như bị lộ password bởi có thể tận dụng nó để lấy được những tài nguyên mà nó đang bảo vệ. Vì vậy, access token có một thời kì sử dụng nhất định (vài giờ, 2 tháng…) tùy thuộc vào nhu cầu sử dụng cũng như yêu cầu về tính chất bảo mật thông tin. Access token chỉ được sử dụng một lần duy nhất, khi nó hết hiệu lực Client sẽ phải gửi lại yêu cầu đến Authorization server để lấy một mã access token mới.

2. Refresh token

Được sinh ra bởi Authorization server, cùng lúc với access token nhưng lại khác nhau về chức năng. Refresh token sẽ tiến hành gửi đi để lấy về một access token mới khi nó hết hạn, cũng chính vì vậy nó có thời kì hiệu lực lâu hơn access token. Với access token thời kì hiệu lực có thể là vài giờ thì refresh token có thể lên tới 10 giờ.

Việc có mặt của refresh token hỗ trợ cho Client có thể lấy lại được access token mà không cần thiết phải nhận xác thực lại từ phía người dùng. Nếu người dùng đăng xuất, refresh token cũng sẽ bị xóa theo.

Xem Thêm : Sàn HNX là gì? Quy định giao dịch trên sàn HNX

Scope là một thông số được khái niệm trong Authorization server dùng để làm giới hạn quyền, phạm vi tài nguyên mà access token được phép truy cập. Client sẽ xác định sử dụng scope nào khi yêu cầu sinh ra một đoạn access token.

OAuth2 có 4 loại định danh chính:

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

Trước lúc đi vào cụ thể chi tiết từng loại của OAuth2, tất cả chúng ta cùng tìm hiểu qua 2 thuật ngữ dùng để làm xác nhận Client với Authorization server:

• Client Identifier (Client ID): chuỗi ký tự được sử dụng để định danh ứng dụng.
• Client Secret: là một chuỗi ký tự dùng cho việc 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ữ kín đáo giữa Client và Authorization Server.

Có thể hiểu Client ID là username, Client Secret là password của Client khi đối chiếu với Authorization cũng được.

1.Authorization Code

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

Ví dụ:

• Resource Owner: Là bạn
• Resource Server: Sever Google
• Client: Bất kỳ website nào
• Authorization Server: Sever Google

Cách hoạt động:

• Người dùng click vào nút đăng nhập trên ứng dụng web.
• Ứng dụng web chuyển hướng người dùng đến Authorization server để mở màn quá trình nhận authorization code.
• Người dùng được chuyển đến trang đăng nhập.
• Người dùng nhập thông tin đăng nhập để xác thực ví dụ như nhập username và password.
• Authorization server sẽ 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 bắt thông tin trả về từ Authorization server) kèm theo một đoạn “authorization code”.
• Ứng dụng (Client) gửi request đến Authorization server gồm Client ID, Client sercret (đã khai báo với Authorization server trước đó) cùng với đoạn mã authorization code vừa nhận.
• Authorization server sẽ xác minh thông tin mà Client vừa gửi.
• Nếu thông tin mà Client trình lên là hợp thức, Authorization sẽ trả về access token cùng với refresh token (nếu có).
• Ứng dụng gửi request tới Resource server kèm theo Access token vừa nhận được.
• Resource server kiểm tra access token, nếu hợp thức thì trả về cho Client tài nguyên tương ứng mà access token được cho phép truy cập.

2. Resource Owner Password Credentials

Loại này được cho phép các ứng dụng bên thứ 3 có thể lấy về token bằng phương pháp sử dụng các thông tin từ tài khoản của người dùng. Loại này được thẩm định và đánh giá là không được bảo mật thông tin hơn Authorization Code, nên làm dùng ở một số website lớn hoặc thực sự tin tưởng bởi vì nó trực tiếp xử lý thông tin tài khoản của người sử dụng.

Cách hoạt động:

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

3. Implicit

Loại này thường được sử dụng cho những ứ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 thẳng đến ứng dụng thông qua URI trên trình duyệt (browser). Phương thức này hoàn toàn tin vào URI đã đăng ký trước này mà không cần thông qua bất kỳ phương thức xác thực nào khi đối chiếu với phía ứng dụng (Client).

Xem Thêm : Tìm hiểu về quả cam mật nổi tiếng ở miền Tây

Loại xác thực này sẽ không tương trợ refresh token.

Cách hoạt động:

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

4. Client Credentials

Loại ủy quyền này nhằm phục vụ cho mục tiêu 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ó hiện vẫn đang nắm giữ.

Cũng như loại trên, Client Credentials không tương trợ refresh token.

Cách hoạt động:

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

Trên đây là những phần cơ bản về OAuth2 mà mình có thể tìm hiểu được, hy vọng chúng sẽ giúp ích được cho những ban phần nào.

Nội dung bài viết dựa trên những hiểu biết member nên không tránh khỏi những thiếu sót, mọi người dân có thắc mắc hay phản hồi gì thì hãy comment xuống phía dưới để mình có thể trả lời cũng như bổ sung để nội dung bài viết được hoàn thiện hơn.

Cảm ơn các bạn đã theo dõi nội dung bài viết.

https://auth0.com/docs