用於Azure的JWT身份驗證/授權的Stormpath

Question

我們正在研究移動報告應用程序的身份驗證/授權，該應用程序使用運行在MS Azure雲中的內部提供的RESTful Web API服務通過網絡消耗每小時/每周/每月的商業敏感數據。 Stormpath的產品看起來很有趣，因為它似乎可以為整個身份管理方面，注冊用戶，對其進行身份驗證以及生成JWT令牌等方面帶來很大的負擔。否則，我們將不得不編寫自己的auth / user db表，並擁有與此相關的一些管理開銷。

我還不太清楚的是，Azure提供的當前不安全，未經身份驗證的原型API在何處需要與Stormpath相交。 任何人都可以對此進行闡述，特別是那些熟悉Stormath的人嗎？

我知道所有用戶注冊，密碼恢復用例都將通過Stormpath進行，而且我猜想為用戶創建JWT令牌將需要我們現有的服務與Stormpath進行通信。 RESTful調用的HTTP（S）標頭中的令牌驗證是否將由我們的Azure服務在本地（通過某些代碼插件）完成，如果是，那么驗證是在本地完成還是每個RESTful調用都會產生代理調用的副作用Stormpath API可以驗證令牌的優劣？

我想我對與Web API管道中的整個令牌驗證步驟有關的性能問題很敏感。

我在其他地方讀過，Microsoft本身提供了一個產品，即Azure AD B2C，它似乎尚未針對美國/北美以外的地區進行生產。 除了Stormpath之類的外包產品，我們還應該考慮其他方法嗎？

關於Stormpath之類的東西看起來很有吸引力的一件事是可以進行兩因素身份驗證。 在沒有進行過多分析的情況下，典型的用例場景是注冊或密碼恢復將強制要求將SMS發送到用戶的預注冊智能手機號碼，以更強地驗證用戶（及其預注冊設備）是使用RESTful服務來消費和可視化商業敏感數據的移動應用程序的目標用戶。

Answer 1

我在.NET庫的Stormpath工作。

我還不太清楚的是，Azure提供的當前不安全，未經身份驗證的原型API在何處需要與Stormpath相交。

Stormpath充當您API的訪問令牌的來源。 當使用您的移動應用程序的某人需要登錄時，您的后端API使用Stormpath生成訪問令牌，或者移動應用程序直接與Stormpath對話以獲取訪問令牌。 無論哪種方式，令牌都允許移動應用向您的API發出經過身份驗證的請求。

RESTful調用的HTTP（S）標頭中的令牌驗證是否將由我們的Azure服務在本地（通過某些代碼插件）完成，如果是，那么驗證是在本地完成還是每個RESTful調用都會產生代理調用的副作用Stormpath API可以驗證令牌的優劣？

可以使用中間件（如ASP.NET中的UseJwtBearerAuthentication在本地驗證訪問令牌（JWT）的完整性。 為了提高安全性，您可以將令牌發送到Stormpath進行進一步驗證（以用於吊銷和其他情況），但要權衡是網絡請求。 本地（快速）驗證是默認設置，但我們為您提供了兩種選擇。

我在其他地方讀過，Microsoft本身提供了一個產品，即Azure AD B2C，它似乎尚未針對美國/北美以外的地區進行生產。 除了Stormpath之類的外包產品，我們還應該考慮其他方法嗎？

使用Stormpath或Azure AD B2C都可以“外包”您的身份和用戶管理。 好處是您不必自己編寫它，而可以專注於編寫業務和應用程序邏輯。 這些功能是相似的，盡管Stormpath在移動方面更靈活（因為您沒有被迫使用基於瀏覽器/頁面的流程）。