API nên sử dụng xác thực cơ bản http như thế nào

Khi một API yêu cầu khách hàng xác thực nó, tôi đã thấy hai kịch bản khác nhau được sử dụng và tôi tự hỏi tôi nên sử dụng trường hợp nào cho tình huống của mình.

Ví dụ 1. API được cung cấp bởi một công ty để cho phép các bên thứ ba xác thực bằng mã thông báo và bí mật bằng HTTP Basic.

Ví dụ 2. API chấp nhận tên người dùng và mật khẩu qua HTTP Basic để xác thực người dùng cuối. Nói chung, họ nhận được mã thông báo cho các yêu cầu trong tương lai.

Thiết lập của tôi: Tôi sẽ có API JSON mà tôi sử dụng làm phụ trợ cho ứng dụng di động và web. Có vẻ như cách tốt cho cả ứng dụng di động và web để gửi mã thông báo và bí mật để chỉ hai ứng dụng này có thể truy cập API chặn bất kỳ bên thứ ba nào khác.

Nhưng ứng dụng di động và web cho phép người dùng đăng nhập và gửi bài đăng, xem dữ liệu của họ, v.v. Vì vậy, tôi cũng muốn họ đăng nhập qua HTTP Basic theo từng yêu cầu.

Tôi bằng cách nào đó có sử dụng kết hợp cả hai phương pháp này hay chỉ gửi thông tin đăng nhập của người dùng cuối (tên người dùng và mã thông báo) cho mỗi yêu cầu? Nếu tôi chỉ gửi thông tin đăng nhập của người dùng cuối, tôi có lưu trữ chúng trong cookie trên máy khách không?

api rest authentication

— Paul Sylling
nguồn

Lưu ý rằng cookie không phải là một phần của giao thức HTTP và chỉ là một tính năng phổ biến của trình duyệt. Vì vậy, nếu bạn không triển khai cho web, hãy quên chúng đi.

— Yam Marcovic

Nếu cookie không được đề xuất, làm thế nào / nơi bạn lưu trữ các khoản tín dụng để chuyển đến api?

— Paul Sylling

Cookies chỉ là một cách để người dùng trình duyệt lưu trữ mã thông báo phiên một cách liền mạch. Nếu bạn đang tương tác với nhà phát triển, điều này không cần phải liền mạch. Bạn có thể thiết lập một dịch vụ kết nối công cộng cấp "vé" và nhà phát triển có thể giữ vé của họ trong bộ nhớ hoặc bất cứ nơi nào họ muốn. Lưu ý rằng tôi không có kinh nghiệm dịch vụ web thực tế và có thể có các giải pháp tiêu chuẩn cho loại công cụ này.

— Yam Marcovic

Suy nghĩ của bạn về phần câu hỏi của tôi về auth auth và api auth của người dùng cuối. Tôi vẫn không chắc chắn về điều này

— Paul Sylling

Câu trả lời:

Xác thực cơ bản HTTP yêu cầu tên người dùng và mật khẩu được gửi với mọi yêu cầu tài nguyên. Tên người dùng: mật khẩu được chuyển trong tiêu đề yêu cầu "Ủy quyền" cơ sở chuỗi được mã hóa với tiền tố "Cơ bản". Nếu tất cả các giao tiếp http của bạn được mã hóa (thông qua ssl), thông tin của người ủy quyền sẽ không thể dễ dàng được sử dụng bởi những kẻ tấn công vì không chắc họ sẽ có thể nắm bắt được thông tin đó.

Mã hóa http http với xác thực cơ bản là đủ.

— Pilling
nguồn

bạn có thể cung cấp một ví dụ về điều này? Đó là những gì tôi cần, chỉ cần RẤT bị mắc kẹt ngay bây giờ ...

— ganders

OAuth / OpenID có thể hoạt động cùng với mã thông báo / bí mật không?

Gần đây tôi đã suy nghĩ về kịch bản sau đây:

Ứng dụng web Front End
Hiểu về API REST
Ứng dụng thiết bị di động, truy cập API REST

Như một bài kiểm tra đơn giản, tôi đã có thể:

Xác thực người dùng thông qua Ứng dụng web bằng OAuth
API REST được ủy quyền qua OAuth, dẫn đến một bí mật được tạo và chuyển lại cho máy khách
Thiết bị di động sau đó sẽ xác thực qua OAuth và sau đó được API REST ủy quyền thông qua bí mật

Điều này sẽ cho phép Ứng dụng thiết bị di động xác thực với cùng thông tin đăng nhập như thông qua Web Front End (cùng một tài khoản) và cũng có thể cho phép truy cập API.

— Brendan xanh
nguồn

Vì vậy, trong ví dụ của bạn chỉ có người dùng đang xác thực. Các khách hàng đang thực hiện các cuộc gọi tới API (ứng dụng web, ứng dụng di động) không xác thực họ là ai. Về mặt lý thuyết, API là công khai và bất kỳ ứng dụng nào cũng có thể đăng tên người dùng và mật khẩu và có khả năng lấy lại mã thông báo

— Paul Sylling

Người dùng đang xác thực thông qua Ứng dụng và ứng dụng đang thực hiện các cuộc gọi thay mặt cho người dùng. Quá trình xác thực xuất phát mã thông báo, sau đó ứng dụng sẽ chuyển qua.

— Brendan Green