Họ đang đo gì
Bạn có phân biệt được “ai đó là ai” với “ai đó được phép làm gì” không.
Trả lời ngắn~30 giây
OAuth 2.0 là giao thức UỶ QUYỀN: nó cấp cho ứng dụng của bạn một access token để gọi API thay mặt người dùng. Nó không nói người dùng đó là ai — access token là một tấm vé, không phải một giấy tờ tuỳ thân. OpenID Connect là lớp mỏng đặt trên OAuth, thêm một id_token dạng JWT có chữ ký chứa danh tính người dùng. Nếu bạn đang làm “đăng nhập bằng Google” thì thứ bạn cần là OIDC.
Giải thích sâu
Hậu quả thực tế của việc nhầm: nếu bạn xác thực người dùng bằng cách gọi một API “lấy thông tin tôi” với access token, bạn không có cách nào biết token đó được cấp cho ỨNG DỤNG NÀO. Một ứng dụng khác có thể lấy token hợp lệ của người dùng rồi đưa cho bạn, và bạn đăng nhập họ vào tài khoản của người đó. Đây là confused deputy, và id_token giải quyết nó bằng trường aud — nói rõ token này dành cho ai.
Về luồng, khuyến nghị hiện nay đã hội tụ: Authorization Code cộng PKCE cho tất cả — web, mobile và cả SPA. Implicit flow bị khuyến cáo bỏ vì nó trả token qua fragment của URL, nơi nó lọt vào lịch sử trình duyệt và referrer. Nói được rằng implicit đã lỗi thời là một tín hiệu tốt, vì rất nhiều tài liệu trên mạng vẫn dạy nó.
Câu hỏi tiếp theo họ sẽ hỏi
?PKCE giải quyết vấn đề gì?
Việc chặn mã uỷ quyền. Client sinh một secret ngẫu nhiên, gửi đi bản băm của nó khi bắt đầu, rồi gửi bản gốc khi đổi mã lấy token — nên kẻ chặn được mã cũng không đổi được. Ban đầu thiết kế cho mobile, giờ khuyến nghị cho cả client có secret.
Trả lời thế này là mất điểm
- Dùng access token làm bằng chứng danh tính. Đó chính là lỗ hổng confused deputy, và nó đã xảy ra ở những sản phẩm rất lớn.