OAuth bên trong VPN: những chặng nào vẫn cần TLS

Định tuyến riêng quyết định ai tiếp cận được máy chủ; các quy tắc vận chuyển OAuth quyết định cách mỗi thông điệp di chuyển. Một trình duyệt, một máy chủ ủy quyền, một điểm cuối token và một máy chủ tài nguyên đều có thể nằm sau cùng một VPN mà vẫn trao đổi thông điệp qua những chặng khác nhau. Mỗi chặng có yêu cầu vận chuyển riêng, và VPN không nới lỏng bất kỳ yêu cầu nào trong số đó. Ranh giới VPN và ranh giới giao thức là hai đường khác nhau.

Quyết định sẽ dễ hơn nếu bạn ngừng hỏi mạng có đáng tin hay không và bắt đầu hỏi trao đổi nào đang vượt qua ranh giới nào.

Quyết định theo chặng, không theo mạng

Hãy ghi các điểm cuối riêng ra: điểm cuối ủy quyền, điểm cuối token, URI chuyển hướng, URL máy chủ tài nguyên, điểm kết thúc TLS và cổng VPN. Sau đó đánh dấu bên nào khởi tạo mỗi yêu cầu và phản hồi đi đâu.

Một VPN kết thúc tại cổng sẽ mã hóa đoạn đến cổng đó. Yêu cầu có thể tiếp tục dưới dạng HTTP thường phía sau nó, và chặng còn lại đó không trở thành HTTPS chỉ vì một đoạn trước đó đã được mã hóa. Chính phần tiếp nối đó là chặng mà giao thức quan tâm. Mã hóa chặng đầu không làm chặng thứ hai an toàn.

Việc vận chuyển còn mang theo một bước kiểm tra danh tính dịch vụ. Trình duyệt xác thực chứng chỉ cho URL ứng dụng; VPN không thực hiện việc xác thực đó thay trình duyệt và cũng không làm cho một điểm cuối chưa được xác thực trở nên chấp nhận được. Chứng chỉ nêu tên điểm cuối mà ứng dụng khách tin rằng mình đang gọi. Một đường hầm đến cổng không đổi tên hay xác thực điểm cuối đó.

Phản hồi ủy quyền và URI chuyển hướng

Thực hành bảo mật tốt nhất hiện hành của OAuth cấm truyền phản hồi ủy quyền qua các kết nối không mã hóa. Điều đó bao gồm cả chuyển hướng mang mã ủy quyền hoặc token về cho ứng dụng khách, không chỉ yêu cầu ban đầu.

Hướng dẫn tương tự cũng không cho phép URI chuyển hướng HTTP, trừ trường hợp loopback dành cho ứng dụng khách gốc đã được chỉ định. Một tên máy chủ nội bộ không tạo ra ngoại lệ mới, và một tên DNS chỉ phân giải được bên trong VPN vẫn là URL HTTP nếu lược đồ nói như vậy. Hãy kiểm tra lược đồ trong URI đã đăng ký, không chỉ tên máy chủ.

Đăng ký chính xác URI chuyển hướng HTTPS với máy chủ ủy quyền và giữ bật xác thực chứng chỉ trên ứng dụng khách. Một lối tắt phát triển nhằm dập tắt yêu cầu HTTPS sẽ tạo ra luồng hành xử khác với cấu hình thực tế mà nó đáng lẽ phải mô phỏng.

Điểm cuối token và các yêu cầu bearer token

Yêu cầu token mang thông tin đăng nhập hoặc một mã có thể đổi lấy quyền truy cập. Gửi nó qua một chặng không được bảo vệ sẽ làm lộ dữ liệu mà máy chủ tài nguyên sẽ tin tưởng về sau, kể cả khi mạng xung quanh là riêng tư. Một proxy đọc được yêu cầu cũng đọc được thông tin đăng nhập mà nó mang theo.

Đối với các yêu cầu tài nguyên dùng bearer token, RFC 6750 coi TLS là bắt buộc phải triển khai và sử dụng cho đặc tả đó. Việc gọi mạng con của văn phòng là đáng tin không phải là ngoại lệ giao thức chung mà một triển khai bearer dạng văn bản thuần cần đến.

Dùng các URL điểm cuối bảo mật đã được tài liệu hóa cho cả hai chặng. Nếu một thư viện từ chối gọi điểm cuối token HTTP, sự từ chối đó chính là đặc tả đang hoạt động, không phải lỗi cấu hình để lách. Hãy ghi URL đó vào cấu hình ứng dụng khách thay vì suy ra lúc chạy.

TLS kết thúc ở đâu và còn lại gì

Nếu TLS kết thúc tại một frontend được ủy quyền, hãy nêu tên frontend đó và xem xét đường đi từ nó đến ứng dụng. Frontend trở nên chịu trách nhiệm về chuyển tiếp, tin cậy và bảo mật trên đoạn còn lại, và kiến trúc được hỗ trợ của dịch vụ nên mô tả cách bố trí đó.

Một VPN ở chỗ khác trên đường đi không giải quyết những trách nhiệm đó. Nó cũng không cho bạn biết URL ứng dụng mà trình duyệt thấy có khớp với chứng chỉ mà frontend xuất trình hay không.

Đối với triển khai nội bộ, hãy ghi lại điểm kết thúc và danh tính mà nó xuất trình. Một frontend kết thúc TLS bằng chứng chỉ cho tên khác sẽ tạo ra cảnh báo trình duyệt mà người vận hành thường dập tắt thay vì sửa.

Ngoại lệ loopback gốc rất hẹp

Ngoại lệ chuyển hướng loopback liên quan đến một lệnh gọi lại trên thiết bị của chính người dùng, nơi ứng dụng khách và trình duyệt dùng chung thiết bị đó. Cách bố trí đó thuộc về một lệnh gọi lại trên một thiết bị, và nó không cấp phép phục vụ một máy chủ ủy quyền thông thường hay một API mang token qua HTTP cho mạng con văn phòng.

Hãy giữ ngoại lệ trong phạm vi loại ứng dụng khách và lệnh gọi lại mà nó mô tả. Áp dụng nó cho một ứng dụng web, một dịch vụ nội bộ dùng chung hoặc một URI chuyển hướng trên máy chủ khác là thay đổi việc triển khai, không phải thay đổi ngoại lệ.

Hãy kiểm thử luồng thực tế tại từng ranh giới và so sánh với loại ứng dụng khách. Một chuyển hướng hoạt động không nói lên điều gì về việc mọi chặng mang token có dùng biện pháp bảo vệ bắt buộc hay không, và một biểu tượng VPN màu xanh cũng không nói gì về lược đồ của yêu cầu tiếp theo.