Cách truy cập vào API của riêng tôi từ ứng dụng web của tôi một cách an toàn?

Question

Tôi có API. Một số trong số đó bị giới hạn quyền truy cập từ các ứng dụng của bên thứ ba bởi OAuth.

Tôi cũng có ứng dụng web. Người dùng có thể đăng nhập và xem thông tin cá nhân của họ.

API cũng được gọi từ ứng dụng web. Câu hỏi của tôi là cách tốt để truy cập API với các biện pháp bảo mật là gì.

1. Third party applications -> OAuth 

2. My own web application -> ??? 

Ứng dụng web của tôi sử dụng id phiên để xác thực. Tôi đoán rằng chuyển id phiên với tiêu đề HTTP có thể là cách tốt nhưng tôi không có một sự tự tin.

Đối exmaple ...

$ curl -X PUT \ 
     -H "X-Sample-Application-Id: "My own web application's ID" \ 
     -H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \ 

Nếu API nhận được yêu cầu này, sử dụng phiên để xác thực thay vì oauth và xác định người sử dụng ....

Bất kỳ trợ giúp sẽ được đánh giá cao.

Cảm ơn,

.. Tôi tìm thấy câu hỏi tương tự

Questions About Consuming Your Own API with OAuth

---

Update1

Một số người nói JWT (Json Web Token) là tốt.

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html

---

Update2

Tôi có thể sử dụng "tài nguyên Chủ Mật khẩu Credentials" OAuth của

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

Hoặc ... "Khách hàng Crede ntials cấp "có vẻ tốt hơn nhiều.

Answer 1

Tôi sẽ giải thích một chút về điều này, bởi vì đó là một câu hỏi hay, và có rất nhiều sự nhầm lẫn xung quanh nó - vì vậy hãy để tôi ở đây.

Nếu API bạn đang cố gắng bảo vệ sẽ được sử dụng độc quyền bởi các cá nhân cho ứng dụng phía máy chủ và không phải nhà phát triển bên thứ ba, tôi rất muốn giới thiệu bạn sử dụng Xác thực cơ bản HTTP để bảo mật dịch vụ API của bạn .

Cách làm việc này là siêu thẳng về phía trước:

• Đối với người dùng của bạn (s), tạo ra API cặp Key (s) mà bao gồm một ID và Secret. Khóa API đồng nghĩa với tên người dùng/mật khẩu. Chỉ cần tạo các giá trị ID/Bí mật ngẫu nhiên bằng cách sử dụng thư viện UUID.

• Khi bạn xác thực dựa vào dịch vụ API của mình, hãy cung cấp các thông tin đăng nhập API đó trong tiêu đề Cấp quyền HTTP để tự xác định.Đây là cách có vẻ sử dụng curl:

  $ curl --user my-api-keyid:

  : my-api-key-bí mật https://api.myservice.com/blah

  gì tuyệt vời về cơ bản Auth đó là

• Nó rất đơn giản để thực hiện.
• Đó là một tiêu chuẩn được xác định rõ.
• Miễn là bạn đang đưa ra yêu cầu qua HTTPS và bạn không công bố khóa API của mình, bạn nên an toàn.

Bây giờ - nếu bạn đang xây dựng dịch vụ API nơi bạn muốn xác thực người dùng từ nhiều môi trường khác nhau (không chỉ ứng dụng phía máy chủ), bạn thực sự cần sử dụng giao thức OAuth2.

Đây là nội dung được thiết kế cho.

Giao thức OAuth2 có thể xác thực người dùng theo nhiều cách - nhưng kết quả là khá phức tạp. Thêm OAuth để trang web của bạn có thể là một thách thức, thậm chí nếu bạn đang sử dụng các thư viện phổ biến/vv

Sau đây là cách OAuth hoạt động (một sự cố nhanh chóng):

Password Grant

Password luồng trong OAuth là nơi bạn trao đổi tên người dùng/mật khẩu cho Mã thông báo truy cập (thường là một JWT). Sau đó, bạn sử dụng Mã thông báo truy cập trong tiêu đề Cấp quyền HTTP để xác định chính mình với dịch vụ API của bạn.

Đây là những gì hầu hết mọi người làm khi xây dựng SPA với Angular/React, cũng như các ứng dụng dành cho thiết bị di động.

Các Credentials Khách hàng Grant

The Client Credentials chảy là nơi bạn trao đổi một khóa API (giống như auth cơ bản) cho một Access Token. Sau đó, bạn sử dụng Mã thông báo truy cập trong tiêu đề Cấp quyền HTTP để xác định chính mình với dịch vụ API của bạn.

Đây là những gì mọi người làm khi xây dựng các ứng dụng phía máy chủ với OAuth.

Các Grant Implicit

dòng chảy Đây là những gì bạn nhìn thấy khi bạn đăng nhập vào một số vị trí như Facebook. Bạn nhấp vào một nút, được chuyển hướng đến một số trang web khác để xác thực/chấp nhận quyền và cuối cùng bạn được trả lại trang web chính bằng Mã thông báo xác thực mà bạn sử dụng để nhận diện chính mình. Điều này là không lý tưởng cho các dịch vụ API.

Các Authorization Mã Grant

dòng này hoàn toàn giống với dòng chảy ngầm, ngoại trừ bạn có được trở lại một mã số cho phép mà bạn sau đó đổi lấy một access token mà bạn sử dụng để xác định chính mình. Điều này là không lý tưởng cho các dịch vụ API. Nó an toàn hơn một chút.

Nếu bạn dự định đi với OAuth vì trường hợp sử dụng của bạn, tôi khuyên bạn nên kiểm tra nhà cung cấp xác thực như Stormpath.Chúng tự động hóa rất nhiều thứ này và giải quyết rất nhiều sự phức tạp xung quanh OAuth.

Nếu không, hãy cho phép Xác thực cơ bản!