Identity Server 4 – The Big Picture (p1)

4 min read

Trong bài viết này tôi chỉ đề cập đến tổng quan (The Big Picture) về IdentityServer

Hầu hết các ứng dụng hiện đại trông ít nhiều giống thế này:

Các tương tác phổ biến nhất là:

  • Trình duyệt giao tiếp với các ứng dụng web
  • Các ứng dụng web giao tiếp với các API web (đôi khi là của chính chúng, đôi khi thay mặt cho người dùng)
  • Các ứng dụng dựa trên trình duyệt giao tiếp với API web
  • Các ứng dụng gốc giao tiếp với API web
  • Các ứng dụng dựa trên máy chủ giao tiếp với API web
  • API web giao tiếp với API web (đôi khi là API web, đôi khi thay mặt người dùng)

Thông thường, mỗi lớp (front-end, middle-tier và back-end) đều phải bảo vệ tài nguyên và triển khai xác thực và/hoặc ủy quyền – thường đối với cùng một cửa hàng người dùng.

Việc thuê ngoài các chức năng bảo mật cơ bản này cho dịch vụ mã thông báo bảo mật sẽ ngăn chặn việc trùng lặp chức năng đó trên các ứng dụng và điểm cuối đó.

Việc tái cấu trúc ứng dụng để hỗ trợ dịch vụ mã thông báo bảo mật dẫn đến kiến ​​trúc và giao thức sau:

Thiết kế như vậy chia mối quan tâm về bảo mật thành hai phần:

Xác thực

Xác thực là cần thiết khi ứng dụng cần biết danh tính của người dùng hiện tại. Thông thường, các ứng dụng này quản lý dữ liệu thay mặt cho người dùng đó và cần đảm bảo rằng người dùng này chỉ có thể truy cập dữ liệu mà họ được phép. Ví dụ phổ biến nhất cho điều đó là các ứng dụng web (cổ điển) – nhưng các ứng dụng gốc và dựa trên JS cũng cần có nhu cầu xác thực.

Các giao thức xác thực phổ biến nhất là SAML2p, WS-Federation và OpenID Connect – SAML2p là phổ biến nhất và được triển khai rộng rãi nhất.

OpenID Connect là phiên bản mới nhất trong ba phiên bản nhưng được coi là tương lai vì nó có tiềm năng nhất cho các ứng dụng hiện đại. Nó được xây dựng cho các kịch bản ứng dụng di động ngay từ đầu và được thiết kế thân thiện với API.

Truy cập API

Các ứng dụng có hai cách cơ bản để giao tiếp với API – sử dụng danh tính ứng dụng hoặc ủy quyền danh tính của người dùng. Đôi khi cả hai phương pháp cần phải được kết hợp.

OAuth2 là giao thức cho phép các ứng dụng yêu cầu mã thông báo truy cập từ dịch vụ mã thông báo bảo mật và sử dụng chúng để giao tiếp với API. Việc ủy ​​quyền này làm giảm độ phức tạp trong cả ứng dụng khách cũng như API vì việc xác thực và ủy quyền có thể được tập trung hóa.

OpenID Connect và OAuth 2.0 – cùng nhau tốt hơn

OpenID Connect và OAuth 2.0 rất giống nhau – trên thực tế OpenID Connect là một tiện ích mở rộng trên OAuth 2.0. Hai mối quan tâm bảo mật cơ bản, xác thực và truy cập API, được kết hợp thành một giao thức duy nhất – thường chỉ với một chuyến đi khứ hồi tới dịch vụ mã thông báo bảo mật.

Chúng tôi tin rằng sự kết hợp giữa OpenID Connect và OAuth 2.0 là cách tiếp cận tốt nhất để bảo mật các ứng dụng hiện đại trong tương lai gần. IdentityServer4 là sự triển khai của hai giao thức này và được tối ưu hóa cao độ để giải quyết các vấn đề bảo mật điển hình của các ứng dụng di động, ứng dụng gốc và ứng dụng web ngày nay.

IdentityServer4 có thể trợ giúp như thế nào

IdentityServer là phần mềm trung gian bổ sung các điểm cuối OpenID Connect và OAuth 2.0 tuân thủ thông số kỹ thuật vào một ứng dụng ASP.NET Core tùy ý.

Thông thường, bạn xây dựng (hoặc sử dụng lại) một ứng dụng có chứa trang đăng nhập và đăng xuất (và có thể có sự đồng ý – tùy thuộc vào nhu cầu của bạn) và phần mềm trung gian IdentityServer thêm các đầu giao thức cần thiết vào đó để các ứng dụng khách có thể giao tiếp với nó sử dụng các giao thức chuẩn đó.

../_images/middleware.png

Ứng dụng lưu trữ có thể phức tạp như bạn muốn, nhưng chúng tôi thường khuyên bạn nên giữ bề mặt tấn công càng nhỏ càng tốt bằng cách chỉ bao gồm giao diện người dùng liên quan đến xác thực.

Reference

Avatar photo

Leave a Reply

Your email address will not be published. Required fields are marked *