search

hoangquochung1110 / public-notes

0 stars 0 forks source link

OAuth 2.0 #40

Open hoangquochung1110 opened 1 month ago

hoangquochung1110 commented 1 month ago

Hiểu về Xác Thực (Authentication) và Uỷ Quyền (Authorization) trong OAuth 2.0

Định nghĩa

Hãy xem OAuth 2.0 như một framework chuẩn hóa để ủy quyền. Nhiệm vụ chính của nó là cho phép một Application có được một 'giấy phép truy cập' tạm thời cụ thể (Access Token) cho phép nó tương tác với tài nguyên được bảo vệ của User, được lưu trữ bởi một Resource Server.

OAuth 2.0 và Xác thực

Sự khác biệt quan trọng cần nắm là: Bản thân OAuth 2.0 không thực hiện hành động cơ bản xác minh User là ai. Quá trình đó, authentication, là trách nhiệm duy nhất của một thành phần riêng biệt gọi là Authorization Server.

Quy trình OAuth 2.0

  1. User Authentication (Nằm ngoài Phạm vi Trực tiếp của OAuth 2.0):

    • Authorization Server sử dụng cơ chế và chính sách nội bộ của nó để xác minh an toàn danh tính của User (ví dụ: bằng cách kiểm tra thông tin đăng nhập, xác thực security token, hoặc sử dụng bất kỳ phương thức nào khác mà nó cho là phù hợp).
    • OAuth 2.0 không quy định phải thực hiện việc này như thế nào.

  2. User Consent:

    • Sau khi User được authentication thành công, Authorization Server thường hỏi User liệu họ có đồng ý cấp cho Application yêu cầu các quyền cụ thể (scopes) mà nó đang yêu cầu hay không.

  3. Authorization Grant & Token Issuance (Vai trò của OAuth 2.0):

    • Chỉ khi authentication thành công và sự đồng ý được đưa ra, luồng xác định của OAuth 2.0 mới tiếp tục.
    • Điều này dẫn đến việc Authorization Server cấp Access Token cho Application.
    • Token này đại diện cho quyền được cấp.

Tại sao Sự tách biệt này Quan trọng

Specialization

Authorization Server có thể chuyên về User authentication mạnh mẽ, sử dụng các phương thức bảo mật tốt nhất và hiện đại nhất, mà không làm phức tạp đặc tả của OAuth 2.0.

Flexibility

Các dịch vụ khác nhau có thể có cách authentication User khác nhau (ví dụ: simple passwords, complex enterprise single sign-on, hardware tokens). OAuth 2.0 có thể làm việc với bất kỳ phương thức nào trong số đó vì nó không áp đặt các quy tắc authentication riêng.

Security Boundaries

Application muốn truy cập không bao giờ thấy hoặc xử lý thông tin đăng nhập chính của User. User chỉ cung cấp thông tin đăng nhập của họ trực tiếp cho trusted Authorization Server.

Lưu ý: Khi User thấy trang đăng nhập trong quá trình OAuth 2.0, đó là Authorization Server đang thực hiện nhiệm vụ authentication của nó, điều này là điều kiện tiên quyết để quá trình authorization OAuth 2.0 diễn ra.

hoangquochung1110 commented 1 week ago

The 4 Grant Types:

  1. Authorization Code + PKCE

    • Sử dụng: Web applications, mobile apps
    • Bảo mật: Cao nhất, ngăn chặn code interception
    • Trả lời phỏng vấn: "Bảo mật nhất cho public clients"

  2. Client Credentials

    • Sử dụng: Giao tiếp service-to-service
    • Bảo mật: Machine-to-machine authentication
    • Trả lời phỏng vấn: "Microservices của chúng tôi dùng cho API calls"

  3. Resource Owner Password (Legacy)

    • Sử dụng: Trusted first-party applications
    • Bảo mật: Thấp hơn, cần xử lý credentials
    • Trả lời phỏng vấn: "Tránh trừ khi migration legacy"

  4. Implicit Flow (Deprecated)

    • Sử dụng: Trước đây cho SPAs
    • Bảo mật: Dễ bị token interception
    • Trả lời phỏng vấn: "Được thay thế bởi Authorization Code + PKCE"
hoangquochung1110 commented 1 week ago

Các thành phần OAuth2.0 chính

hoangquochung1110 commented 1 week ago

Lựa chọn chính dựa trên user involvement. Mọi consideration khác (security, performance, etc.) là phụ

Authorization Code Grant

✅ App hoạt động THAY MẶT user

Client Credentials

✅ KHÔNG thay mặt user nào cả

⚠️ Ngoài ra còn phụ thuộc vào nhà cung cấp dịch vụ (Authorization Server), ko phải đơn vị nào cũng hỗ trợ đầy đủ grant types