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...

[GN⁺]

Ý kiến Hacker News

• Một người dùng đã triển khai máy chủ OAuth trong intranet của công ty. Một nhóm khác yêu cầu triển khai đăng nhập mà không tuân theo đặc tả chính thức, và cuối cùng đã dẫn đến việc tạo ra một biến thể OAuth không chính thức

• Khi dùng OAuth với nhiều nhà cung cấp và tùy chọn đăng ký bằng email, đôi khi người dùng không nhớ trước đó đã đăng nhập bằng cách nào nên vô tình tạo tài khoản mới

• Một năm trước đã triển khai OAuth cho 100 API phổ biến, và trải nghiệm cũng tương tự như những gì OP mô tả

• Nhiều nhà cung cấp không hỗ trợ prompt=select_account hoặc không yêu cầu người dùng chọn tài khoản để đăng nhập. Đây là vấn đề đặc biệt trong OIDC

• Đã nhận được báo cáo lỗi liên quan đến AWS nhưng không thể tái hiện, nên đã xóa phần đó khỏi bài viết. Tuy vậy, nó vẫn có thể hữu ích như một checklist các vấn đề phổ biến

• Nếu có một bộ kiểm thử chính thức thì sẽ giúp ích cho việc triển khai các tiêu chuẩn mở. Vì khó bám sát đặc tả nên một bộ kiểm thử có thể dùng để xác minh sẽ rất hữu ích

• Vấn đề của Facebook có vẻ là trường hợp dùng framework dịch vụ hiện có để viết OAuth2 nhưng không khớp với đặc tả. Điều này tương tự các vấn đề phổ biến trong scripting

• Một số nhà cung cấp không tuân theo đặc tả và chọn dùng endpoint riêng cho refresh token

• Kêu gọi các nhà cung cấp OIDC/OAuth hỗ trợ SCIM đúng cách và thiết kế hệ thống theo tư duy "API first". Cần cân nhắc lại trước khi chuyển sang GNAP