Tại sao họ chọn Mã thông báo ID OIDC để phục vụ dịch vụ
liên lạc? Tôi đã sử dụng OIDC rất nhiều về phía người dùng, nhưng chưa bao giờ về phía
máy chủ đến phía máy chủ. Vì vậy, nhận Mã thông báo ID cho máy chủ đến máy chủ
giao tiếp cảm thấy rất kỳ lạ. Tôi rất thích một liên kết đến các điểm đến
tài liệu giải thích lựa chọn kiến trúc này trên máy chủ đến máy chủ
bên.. Tôi đã mong đợi một Mã thông báo truy cập OAuth2 với Máy khách
Thông tin xác thực cho tất cả dịch vụ liên lạc với dịch vụ không phải là Mã thông báo ID.
Trong Google Cloud, có hai loại ủy quyền. Dựa trên vai trò (Mã thông báo truy cập OAuth) và dựa trên danh tính (Mã thông báo nhận dạng OIDC). Ủy quyền dựa trên vai trò cung cấp quyền truy cập vào tất cả các tài nguyên dựa trên vai trò. Ví dụ: quyền truy cập của người xem vào tất cả các phiên bản Máy tính. Loại quyền này được quản lý ở cấp Dự án/Thư mục/Tổ chức. Ủy quyền dựa trên danh tính cung cấp quyền truy cập vào một tài nguyên riêng lẻ. Sự khác biệt chính là nơi quyền/vai trò được chỉ định: ở cấp dự án hoặc ở cấp tài nguyên. Vì một vai trò có quá nhiều quyền ở cấp tài nguyên nên bạn cần một cách khác.Đó là cách nhận dạng. Tôi cho John truy cập khóa KMS bí mật2. Danh tính + quyền được lưu trữ ở lớp quản lý truy cập khóa KMS.
Tại sao trường Đối tượng tùy ý? Trong Bộ lập lịch đám mây, nó
có vẻ như miễn là tôi sử dụng tài khoản dịch vụ hợp lệ trong dự án,
Tôi có thể đặt bất kỳ giá trị nào trong trường đối tượng không? Tôi chắc chắn có một lý do
đối với điều này, những người của Google rất thông minh, nhưng điều này giống như một lỗ hổng bảo mật.
Ý tôi là, đối tượng có thể là bất kỳ url hợp lệ nào (tốt nhất tôi có thể nói). Tôi có thể
đưa đối tượng của điểm cuối Cloud Run vào một dự án khác và thực hiện
cuộc gọi đó?
Nếu mã của bạn tạo Mã thông báo nhận dạng, khán giả bắt buộc. Có một số ID ứng dụng khách OAuth do Google quản lý cho phép bỏ qua đối tượng. Vì danh tính và quyền được lưu trữ tại tài nguyên nên việc gọi một điểm cuối Cloud Run khác sẽ không vượt qua kiểm tra danh tính. IMHO trường đối tượng là một phương pháp nhanh chóng để hệ thống nhận dạng kiểm tra trước xem Mã thông báo nhận dạng có được phê duyệt cho lớp IAM hay không.
Rõ ràng là có sự phân chia ở đây giữa AuthN và AuthZ, vì vậy
id_token nói nhiều hơn về authN, nhưng trường đối tượng được xác thực trên
yêu cầu của mã thông báo sẽ chỉ ra Authz vững chắc. NHƯNG với nó là
tùy ý, tôi cảm thấy không thể tin tưởng vào việc xác thực đối tượng
bởi vì bất cứ ai cũng có thể đặt bất cứ thứ gì ở đó. Xin vui lòng cho tôi biết những gì tôi
còn thiếu.
Mã thông báo nhận dạng đã được ký. Chỉ các dịch vụ và mã được ủy quyền mới có thể tạo Mã thông báo nhận dạng. Như tôi đã đề cập ở điểm trước, khán giả không cấp quyền hoặc cấp quyền truy cập. Đây là một bước trong lớp các bước để ủy quyền truy cập dựa trên Mã thông báo nhận dạng. Xác thực cuối cùng là danh tính + quyền được chỉ định tại tài nguyên. Đối tượng không cấp bất kỳ quyền nào trong số đó, nhưng có thể được sử dụng làm bộ lọc để nhanh chóng loại bỏ mã thông báo.
