Thư gửi các nhà cung cấp OAuth

• Thư gửi các nhà cung cấp OAuth

  • GitHub

    • Điểm cuối token trả về mã trạng thái 200 ngay cả khi có lỗi
    • Phản hồi lỗi nên sử dụng mã trạng thái 400 hoặc 401

  • Facebook

    • Điểm cuối token trả về phản hồi lỗi tùy biến
    • Nên là một đối tượng JSON có trường lỗi

  • TikTok

    • Máy chủ dùng tham số client_key thay vì client_id
    • Không có lý do nào để lệch khỏi đặc tả

  • Strava

    • Máy chủ dùng danh sách phân tách bằng dấu phẩy cho tham số phạm vi
    • Đúng ra phải là danh sách phân tách bằng khoảng trắng

  • Naver

    • Máy chủ trả về thời gian hết hạn token dưới dạng chuỗi
    • Đây là vấn đề vượt ra ngoài chuyện có tuân thủ đặc tả hay không

  • Nhiều nhà cung cấp OAuth

    • Nên hỗ trợ HTTP Basic Authentication thay cho tham số client_secret để xác thực client
    • Trong tiêu chuẩn OAuth 2.1, HTTP Basic Authentication là tùy chọn, nhưng PKCE là bắt buộc, dù vậy phần lớn nhà cung cấp vẫn không dùng nó

  • AWS

    • Đã nhận được nhiều báo cáo lỗi khi dùng cùng thư viện client OAuth, nhưng vì không thể tái hiện vấn đề nên đã xóa nội dung liên quan

[rikko]

Khi tham gia xây dựng một dự án dịch vụ công cho người dân, tôi từng có trải nghiệm mất tròn 1 tháng chỉ để triển khai riêng tính năng OAuth (OIDC)...

Vì không thể dùng thư viện bên ngoài nên phải tự hiện thực từng thứ một, nhưng ngoài Kakao và Google ra thì hầu như không có nơi nào tuân thủ chuẩn OAuth cho ra hồn...

Naver thì kiểu chỉ cần đăng nhập được là không có vấn đề gì, đến mức tôi còn tự hỏi như vậy mà cũng dùng được sao; còn Apple thì đến giờ nghĩ lại tôi cũng không nhớ nổi mình đã triển khai thế nào, vì cần lượng mã nhiều gấp hơn 3 lần so với mã OAuth hiện có.

Cũng có những trường hợp mã phản hồi rối tinh rối mù như trong bài viết ở trên, thậm chí có nhà cung cấp còn trả về 418 (I'm a teapot).
Chính vì từng có những trải nghiệm như vậy nên dù các tính năng như đăng nhập mạng xã hội có tiện đến đâu, tôi cũng không còn muốn dùng nữa...