Chọn luồng OAuth cho đúng loại client

OAuth 2.0 có nhiều luồng, và tài liệu thường trình bày chúng như một danh sách để chọn. Thực tế đơn giản hơn nhiều: RFC 9700 (BCP hiện hành) đã loại bỏ gần hết, nên câu hỏi thật chỉ còn một: client này giữ được secret hay không.

SPA, mobile app, desktop app | Không | Authorization Code + PKCE | Web app có backend | Có | Authorization Code + PKCE + client secret | Machine-to-machine, không có người dùng | Có | Client Credentials | TV, thiết bị không có bàn phím | Không | Device Authorization Grant |

Hết. Bốn dòng đó phủ mọi client bạn sẽ gặp.

Ba luồng đã bị loại bỏ và biết vì sao thì quan trọng, vì bạn sẽ gặp chúng trong code cũ:

(1) Implicit (response_type=token) — trả access token thẳng trong URL fragment. Nó tồn tại vì thời 2012 chưa có CORS phổ biến nên SPA không gọi được token endpoint. Vấn đề: token nằm trong URL, nên nó vào history của trình duyệt, vào Referer, vào log của proxy. Và không có refresh token, nên hoặc token sống lâu (tệ) hoặc người dùng đăng nhập lại liên tục.

(2) Resource Owner Password Credentials (ROPC) — client nhận username/password rồi đổi lấy token. Nó phá hoại toàn bộ mục đích của OAuth: người dùng đưa mật khẩu cho client thay vì cho provider, nên không có MFA, không có màn hình đồng ý, và mọi client đều phải được tin tuyệt đối.

(3) Authorization Code không có PKCE — không "bị loại bỏ" mà PKCE trở thành bắt buộc cho mọi client, kể cả client có secret. Lý do: PKCE chặn việc chặn lấy authorization code, và mối đe doạ đó tồn tại với cả client có secret (ví dụ qua một redirect URI bị đăng ký lỏng).

PKCE giải quyết gì, nói ngắn: authorization code đi qua trình duyệt, nên nó có thể bị chặn lấy. PKCE buộc client chứng minh nó là cùng client đã bắt đầu luồng, bằng cách gửi một code_verifier khớp với code_challenge đã gửi lúc đầu. Code bị chặn lấy trở thành vô dụng vì kẻ chặn không có verifier.