nhầm lẫn xác thực api an toàn với oauth2

Question

Tôi đã thực hiện một số điều tra về xác thực api an toàn. Hầu hết mọi người chỉ vào Oauth2 để xác thực api an toàn. Tôi nhìn vào một số resouces, đặc biệt là liên kết này https://developers.google.com/accounts/docs/OAuth2.

Dường như với tôi Oauth2 dành cho ứng dụng của bên thứ ba truy cập dữ liệu của người dùng trong google/facebook (hoặc nhà cung cấp dữ liệu khác).

Vấn đề của chúng tôi là chúng tôi sở hữu dữ liệu, chúng tôi không cần truy cập dữ liệu của bên thứ ba của khách hàng và khách hàng của chúng tôi không có bất kỳ dữ liệu của bên thứ ba nào. Chúng tôi muốn bảo vệ api của chúng tôi với một số loại xác thực.

Đối với trường hợp của chúng tôi, công nghệ thuận tiện cho việc xác thực api an toàn của chúng tôi là gì? Chúng tôi sẽ tiếp xúc với api của chúng tôi như thế này

https://ourdomain.com/api/<endpoint> 

khách hàng của chúng tôi có thể truy cập vào một trang web đầu tiên đăng ký https://ourdomain.com và họ sẽ có thể để có được ClientId và clientKey từ website của chúng tôi để truy cập apis. Khách hàng của chúng tôi có thể tiêu thụ thông qua một số loại xác thực

Answer 1

Nếu tôi hiểu chính xác, những gì bạn cần nó tương tự như OAuth theo cách bạn làm chính xác điều đó trừ đi việc cấp quyền truy cập ứng dụng của bên thứ ba vào tài nguyên của người dùng.

Trong OAuth, có một hệ thống trung tâm quản lý xác thực và ủy quyền bằng cách kiểm tra thông tin đăng nhập của ứng dụng + thông tin đăng nhập của người dùng và yêu cầu mã thông báo ủy quyền. Có nhiều điểm cuối sẽ chấp nhận các mã thông báo ủy quyền này.

Mã thông báo là chuỗi được mã hóa cơ bản chứa thông tin về thông tin đăng nhập của người dùng và một số thông tin khác mà ứng dụng của bạn có thể cần.

Điều bạn cần (tôi tin) là điểm cuối xác thực tương tự, khách hàng truy cập bằng thông tin đăng nhập của nó và nhận mã thông báo.

Vì vậy,
i) Tạo biểu mẫu đăng ký/bảng điều khiển nơi khách hàng có thể đăng ký và nhận thông tin đăng nhập của mình. Hãy xem this.
ii) Xác định điểm cuối HTTP nơi người dùng trao đổi thông tin đăng nhập của mình cho mã thông báo truy cập + mã thông báo làm mới.
iii) Máy khách có thể nhấn điểm cuối tài nguyên với mã thông báo truy cập để thực hiện cuộc gọi được xác thực đến bất kỳ điểm cuối nào của bạn.
iv) Ở mặt sau, bạn cần một dịch vụ phổ biến để xác minh mã thông báo và trích xuất thông tin từ đó.

PS - Đây chỉ là một hệ thống tối thiểu, sẽ có rất nhiều cân nhắc về bảo mật như thế nào nếu một số ứng dụng trái phép truy cập vào mã thông báo truy cập của một số khách hàng.
Bạn có thể tìm thấy nhiều thông tin về tấn công CSRF, noonces, dấu thời gian và các phương pháp khác để giảm thiểu các mối quan tâm về bảo mật.

Answer 2

Trong oAuth 2.0, có một số loại loại trợ cấp. Loại trợ cấp chỉ là một cách để trao đổi một số loại thông tin xác thực cho mã thông báo truy cập. Thông thường, oAuth đề cập đến việc sử dụng của bên thứ ba bằng Cấp quyền bằng mã ủy quyền. Điều này có nghĩa là chuyển hướng người dùng đến trang web của chủ sở hữu tài nguyên để xác thực, điều này sẽ trả lại Mã ủy quyền.

Điều này rõ ràng không có ý nghĩa đối với việc sử dụng oAuth của bên thứ nhất, vì bạn là chủ sở hữu tài nguyên. oAuth 2.0 đã xem xét điều này và bao gồm Cấp chứng chỉ mật khẩu chủ sở hữu tài nguyên cho mục đích này. Trong trường hợp này, bạn có thể trao đổi tên người dùng và mật khẩu cho mã thông báo truy cập ở cấp độ bên thứ nhất.

Xem http://tools.ietf.org/html/rfc6749#section-4.3 để biết thêm chi tiết.

Answer 3

Chỉ cần được rõ ràng với câu hỏi ban đầu:

OAuth2 cần ít nhất một khách hàng và một máy chủ

OP đã tự hỏi làm thế nào để đảm bảo một API REST, và tại sao mọi người đang nói về bên thứ ba cung cấp dịch vụ xác thực (Google, Facebook, ...)

có 2 nhu cầu khác nhau ở đây:

1 - có khả năng để bảo đảm một API cá nhân (ourdomain.com)

Client    Server 
Consumers <----> Your API 

2 - Có thể dùng một API công cộng (Ví dụ nhận được danh sách liên lạc Google của người dùng)

Client    Server 
You  <----> Google APIs 

OP thực sự cần 1: thực hiện một máy chủ OAuth2 trước API riêng của mình.
Có many existing implementations for all languages/frameworks on Github

Cuối cùng, đây là one nice Oauth2 technical explanation, và tôi không biết xấu hổ thực hiện một trong lược đồ của nó ở đây:

Không tôi không làm việc tại Google, tôi chỉ tham gia Google làm ví dụ về nhà cung cấp API công khai.