Chào các bạn đã đến với chủ để tiếp theo của mình. Hôm nay, mình sẽ tiếp tục tìm hiểu về các phương thức Authentication với REST API. Ở bài này, mình sẽ đi qua những nội dung như sau:
Nội dung
1.1. Authentication
Authentication: được định nghĩa là khi thực thể chứng minh danh tính là gì hay nói một cách đơn giản là trả lời cho câu hỏi “who you are”
Dựa trên cấp độ bảo mật, authentication factor có thể thay đổi theo một trong các cách sau:
- Single-Factor Authentication
- Two-Factor Authentication
- Multi-Factor Authentication
Ví dụ: giả sử bạn đã đăng ký 1 account ở 1 website, 2 thông tin không thể thiếu là username và password. Những thông tin này còn được gọi là “Giấy thông hành” – Credentials. Và những lần sau, để vào website bạn cần đưa ra cái “Giấy thông hành” đó.
Việc đăng nhập với username và password là 1 ví dụ của quá trình xác định danh tính – Authentication. Khi bạn chứng minh Danh tính với 1 server, bạn cung cấp thông tin mà chỉ có bạn và server biết. Một khi server biết bạn là ai, nó sẽ tin tưởng và cho phép bạn tiếp cận những thông tin bên trong.
1.2. Authorization
Authorization: được định nghĩa là khi thực thể chứng minh có quyền truy cập, đơn giản như kiểu có một cái chìa khóa nhưng chỉ được phép mở một vài cửa trong nhà chứ không được phép mở tất cả các cửa. Hay nói cách khác nó trả lời cho câu hỏi “what you can do”
Các hình thức phân quyền thường gặp là:
- Role-based authorization: Phân quyền dựa trên vai trò của người dùng. Ví dụ trong WordPress có các role như là Subscriber, Contributor, Author, Editor, Administrator và mỗi một role sẽ có những quyền khác nhau và mỗi người dùng sẽ được phân role có quyền tương ứng. Đối với những hệ thống có nhiều người dùng thì role-based là cách tiếp cận tốt nhất để tiết kiệm thời gian trong việc phân quyền.
- Object-based authorization: Phân quyền theo đối tượng. Cách này sẽ phân quyền cho từng đối tượng cụ thể. Ví dụ những đối tượng trong nhóm A, B được phân quyền chỉnh sửa các bài viết trong danh mục. Nhưng đối tượng trong nhóm A chỉ chỉnh sửa được bài viết trong danh mục C, đối trượng trong nhóm B chỉ chỉnh sửa bài viết trong danh mục D.
2. Các phương thức phổ biến dùng Authentication
2.1. Basic authentication
Ví dụ vừa nói ở trên là form cơ bản nhất của Authentication, tên gọi chuẩn là Basic Authentication, hay được viết tắt là “Basic Auth”. Basic Auth chỉ yêu cầu username và password. Client chỉ cần nhập 2 thông tin trên rồi gửi chúng qua HTTP header cho server, đây gọi là quá trình xin phép – Authorization.
Cấu trúc header:
Authorization: Basic <Base 64 endcode {username:password}>
Khi server nhận được 1 request, nó sẽ kiểm tra Authorization header và so sánh thông tin đó với thông tin Credential mà chúng cất giữ ở DB. Nếu đúng, server sẽ chấp thuận request của client và trả thêm các thông mà client yêu cầu ở phần Body.
Nếu không đúng, server sẽ trả lại mã code 401, báo hiệu rằng quá trình xác thực fail và yêu cầu bị từ chối.
Mặc dù Basic Auth là 1 kỹ thuật thường xuyên được sử dụng nhưng trên thực tế việc nó dùng cùng 1 username và password để truy cập đến API là không an toàn. Bởi vì nó sử dụng phương thức base64 để mã hóa thông tin xác thực. Nếu không may ai đó lấy được đoạn mã này, họ có thể giải mã và đánh cắp username và password của bạn. Hiện nay, trên mạng có rất nhiều trang web support cho việc giải mã này.
2.2. Bearer Authentication
Phương thức này hay còn được gọi là token authentication có thể hiểu đơn giản là “cấp quyền truy cập cho người mang token này”. Bearer token sẽ cho phép truy cập đến một số tài nguyên hoặc url nhất định và thường là một chuỗi string được mã hóa, được sinh ra bởi server trong response để thực hiện request login.
Khi thực hiện bằng phương thức này thì client phải gửi bearer token này trong header để thực hiện request
Cấu trúc header:
Authorization: Bearer <token>Cách thức thực hiện với bearer authentication có thể như sau:
Khi user gửi requesst đến server để lấy một token bằng username, password thông qua SSL, server sẽ trả về một chuỗi access token. Access token này chính là bearer token mà client cần phải gửi vào header nếu muốn thực hiện các request khác để server xác thực user đó là đúng. Token này có thể là một chuỗi mã hóa với các thuộc tính của user, vai trò của user đó. Khi server nhận được token này, sẽ giải mã sau đó sẽ thực hiện validate request đó trong ứng dụng xem user có được quyền thực hiện request đó hay không. Token này thường sẽ có thời hạn (ví dụ: 30 phút sau khi lấy sẽ hết hạn) bởi vì có thể role của user sẽ thay đổi trong quá trình thực hiện. Sẽ có trường hợp ví dụ user đang có role=”Admin” chuyển thành “User”. Nếu token không hết hạn thì token cũ với role=”Admin” vẫn có quyền truy cập với role đó mặc dù đã bị thay đổi.
2.3. API Key Authentication
Phương thức này được tạo ra với mục đích khắc phục những vấn đề của basic authentication. Trong phương thức này, một giá trị key duy nhất sinh (unique key) ra và gán cho user trong lần đầu tiên, biểu thị rằng user đó được xác định. Khi user quay trở lại hệ thống, unique key (có thể được sinh ra từ việc kết hợp giữa thông tin phần cứng, địa chỉ IP và thời gian của server) được sử dụng để chứng minh rằng user là giống với lần đầu tiên.
Rất nhiều api key được gửi dưới dạng là một phần của URL (query string) để giúp nhận biết rằng ai không nên có quyền truy cập, ví dụ như:
http://example.com?api_key=my_secret_keyTrong thực tế thì api key xuất hiện dưới dạng như:
- Authorization Header
- Basic Authen
- Body Data
- Query String
2.4. OAUTH (2.0)
OAuth là viết tắt của Open với Authentication hoặc Authorization. OAuth ra đời nhằm giải quyết các vấn đề trên và xa hơn nữa, đây là một phương thức chứng thực giúp các ứng dụng có thể chia sẻ tài nguyên với nhau mà không cần chia sẻ thông tin username và password.
OAuth bao gồm bốn vai trò khác nhau:
- Resource Server: REST API là một ví dụ, một máy chủ HTTP nơi người dùng có thể tạo, sửa đổi hoặc xóa các bản ghi, tài liệu hoặc tệp.
- Resource Owner: Duy trì quyền sở hữu tài nguyên mà người dùng đã tạo hoặc sửa đổi trên máy chủ và người ủy quyền cho ứng dụng bên thứ 3 truy cập vào tài khoản của họ. Ứng dụng của bên thứ 3 có quyền truy cập hạn chế vào tài khoản của người dùng, dựa trên phạm vi của phạm vi của ủy quyền được cấp.
- Client: Ứng dụng bên thứ 3 muốn truy cập vào tài khoản người dùng. Trước khi nó có thể làm như vậy, máy chủ resource/authorization và chủ sở hữu tài nguyên phải ủy quyền cho yêu cầu đó. Mọi khách hàng phải được đăng ký với máy chủ authorization và sẽ được cung cấp cho nó thông tin xác thực duy nhất của riêng mình (client_id và client_secret) để xác thực riêng.
- Authorization Server (thường là giống Resource Server): Đôi khi, ta có thể muốn rút ra khỏi máy chủ authorization từ máy chủ resource và triển khai nó như một phiên bản chuyên dụng, đặc biệt là trong các môi trường phân tán.
Ví dụ: Khi ta đăng nhập bằng Facebook hay Gmail, website sẽ dẫn ta đến trang Facebook và liệt kê những quyền mà nó cần phải có để cho phép bạn đăng nhập và sử dụng dịch vụ. Nếu ta đồng ý thì lúc này Facebook sẽ phát cho website một cái token Token này chứa một số quyền hạn nhất định giúp cho website có thể xác minh chúng ta là ai cũng như giúp cho website có thể hoạt động được. Nếu website này bị hacker tấn công thì nó chỉ lấy được thông tin hay hoạt động của ta trên website đó mà không ảnh hưởng đến những website khác đang sử dụng. Do đó cách đăng nhập bằng phương thức OAuth này rất an toàn cho người dùng cuối như chúng ta.
2.5. Sơ đồ luồng hoạt động của OAuth2
- Ứng dụng (website hoặc mobile app) yêu cầu ủy quyền để truy cập vào Resource Server (Gmail,Facebook, Twitter hay Github…) thông qua User
- Nếu User ủy quyền cho yêu cầu trên, Ứng dụng sẽ nhận được ủy quyền từ phía User (dưới dạng một token string)
- Ứng dụng gửi thông tin định danh (ID) của mình kèm theo ủy quyền của User tới Authorization Server
- Nếu thông tin định danh được xác thực và ủy quyền hợp lệ, Authorization Server sẽ trả về cho Ứng dụng access_token. Đến đây quá trình ủy quyền hoàn tất.
- Để truy cập vào tài nguyên (resource) từ Resource Server và lấy thông tin, Ứng dụng sẽ phải đưa ra
access_tokenđể xác thực. - Nếu
access_tokenhợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên đã được yêu cầu cho Ứng dụng.
3. Kết
Như vậy chúng ta đã tìm hiểu về về các phương thức Authentication với REST API. Cảm ơn các bạn đã theo dõi bài viết của mình. Chúc các bạn thành công. Hẹn gặp lại các bạn ở những chủ đề tiếp theo. Bái bai.
Nguồn: