Những chi tiết kỹ thuật nào các lập trình viên nên xem xét trong khi phát triển dịch vụ oAuth của riêng họ?

8

Những chi tiết kỹ thuật nào các lập trình viên nên xem xét trong khi phát triển dịch vụ oAuth của riêng họ?

Đã cố gắng tìm hiểu các hướng dẫn, nhưng tìm thấy hầu hết các oAuthbài viết liên quan thảo luận như một quan điểm của người tiêu dùng ( tức là làm thế nào để tiêu thụ dịch vụ khác ). Tôi muốn thiết kế oAuthhệ thống của riêng mình với dịch vụ ủy quyền và dịch vụ tài nguyên. Tôi nên làm theo chi tiết kỹ thuật nào?

— Sazzad Hissain Khan
nguồn

1

Phát triển dịch vụ oAuth của riêng bạn có thể rất phức tạp. Phụ thuộc vào những gì bạn thực sự muốn đạt được và những gì Xác thực mà bạn muốn hỗ trợ, ví dụ như Cấp quyền ngầm, Mã ủy quyền, v.v. Nếu bạn sử dụng một trong những nhà cung cấp xác thực nổi tiếng như Azure AD, Cognito, Okta, Auth0.com, v.v. mui xe. Họ không chỉ cung cấp triển khai máy chủ mà còn SDK khách để tự động làm mới mã thông báo, v.v. Thực hiện đầy đủ Bạn cần biết các luồng xác thực ít nhất, auth2.0, giao thức OpenID Connect, Tokens, bảo mật và có thể các bit khác mà tôi không biết.

— Imran Arshad

Bạn đã xem xét KHÔNG xây dựng nó? :) Đùa sang một bên, một dịch vụ oAuth rất hiếm khi là một phần của đề xuất giá trị của một công ty, và thậm chí hiếm khi là một yếu tố khác biệt, ngụ ý rằng hầu hết các công ty tốt hơn nên sử dụng hoặc mua một giải pháp sẵn có. Tất nhiên, điều đó không có nghĩa là không có trường hợp hợp lệ trong đó một cái gì đó như thế này có ý nghĩa kinh doanh, nhưng nó phải được giải thích rõ ràng.

— Savvas Kleanthous

1

@AKleanthus Tôi đã cập nhật tiêu đề. Tôi nghĩ rằng nó đã gây hiểu nhầm trước đây.

— Sazzad Hissain Khan

4

Bạn có thể đã đọc RFC nhưng chỉ trong trường hợp bạn chưa có, chúng là nơi bạn muốn bắt đầu:

oAuth 2.0 "lõi" (RFC 6749 và 6750 )
Khóa chứng minh cho trao đổi mã (PKCE) (RFC 7636 )

Hướng dẫn 'đóng gói' tốt nhất cho người triển khai oAuth (khách hàng hoặc cách khác) có sẵn thông qua Thực tiễn tốt nhất hiện tại (BCP) của IETF. Hầu hết mọi người biết về RFC của IETF và BCP (khó hiểu) được xuất bản dưới dạng RFC với số RFC. Mặc dù vậy, chúng là những thực tiễn tốt nhất và không phải là thông số kỹ thuật chính thức :

Quy trình BCP tương tự như quy trình được đề xuất. BCP được gửi tới IESG để xem xét và quy trình đánh giá hiện tại được áp dụng, bao gồm cả "cuộc gọi cuối cùng" trong danh sách gửi thư thông báo của IETF. Tuy nhiên, một khi IESG đã phê duyệt tài liệu, quy trình kết thúc và tài liệu được xuất bản. Tài liệu kết quả được xem là có sự chấp thuận kỹ thuật của IETF, nhưng nó không phải và không thể trở thành một Tiêu chuẩn Internet chính thức.

BCP bạn muốn xem xét:

oAuth bảo mật (cập nhật khi viết bài này)
oAuth cho các ứng dụng dựa trên trình duyệt (cập nhật khi viết bài này).
oAuth cho các ứng dụng gốc (được xuất bản năm 2017 dưới dạng bản cập nhật cho "lõi" oAuth 2.0 RFC, vẫn là một bản đọc tốt)
Mã thông báo web JSON cho oAuth (cập nhật)

Các tài liệu này được đóng khung trong các điều khoản mô hình mối đe dọa - chúng bao gồm các cuộc tấn công (hoặc "cân nhắc bảo mật" dưới dạng định dạng bị pha loãng) và các biện pháp đối phó. Bạn có thể đang tìm kiếm một loại khối xây dựng đơn giản hơn của một lộ trình và có lẽ nên có một công cụ giáo dục. Việc triển khai oAuth trong thế giới thực phải được phát triển với bằng chứng prima facie về mô hình mối đe dọa.

Như một samurai đã nói : ... kiếm thuật chưa được thử nghiệm trong trận chiến giống như nghệ thuật bơi thành thạo trên cạn.

— nhận dạng
nguồn

2

Tôi cũng sẽ quan tâm để nghe lý do tại sao bạn muốn phát triển giải pháp xác thực của riêng bạn.

Nhưng đặt điều đó sang một bên, có một dự án nguồn mở thực hiện chính xác những gì bạn yêu cầu - Máy chủ Nhận dạng . Bạn có thể kiểm tra mã nguồn của họ hoặc phân tách nó và xây dựng một cái gì đó trên đầu trang của nó.

Ngoài ra, vui lòng kiểm tra câu trả lời "nhận dạng" trên các tài liệu khác nhau.

— eddyP23
nguồn