其中哪一個最容易設置服務器到服務器的JWT?我是否已經有一個現有的JWT令牌來設置整個服務器來傳遞令牌?IdentityServer 4或OpenIddict?
我有一個需求用例來爲另一臺服務器上託管的Web API創建一個客戶端,但無法弄清楚如何將.NET Core中的憑據傳遞給其他服務器,我只需要能夠構建一個GET和使用C#的POST到遠程服務器API並構建一些圖表來顯示GET的結果。
其中哪一個最容易設置服務器到服務器的JWT?我是否已經有一個現有的JWT令牌來設置整個服務器來傳遞令牌?IdentityServer 4或OpenIddict?
我有一個需求用例來爲另一臺服務器上託管的Web API創建一個客戶端,但無法弄清楚如何將.NET Core中的憑據傳遞給其他服務器,我只需要能夠構建一個GET和使用C#的POST到遠程服務器API並構建一些圖表來顯示GET的結果。
如果你已經有一個令牌,那麼你不需要IdentityServer4或OpenIddict。 IdentityServer4和OpenIddict根據請求發佈令牌,但您似乎已經在本地發佈了它們。
我使用通過HTTPS進行POST的表單將我的令牌從站點A發送到站點B.
<form action="https://other-server.example.com/Account/" method="post" id="form">
<input name="token" type="hidden" value="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...">
</form>
您也可以使用JavaScript自動提交表單。
<script>
document.getElementById('form').submit();
</script>
實現標準協議(如OAuth2或OpenID Connect)的積極方面之一是威脅模型通常是衆所周知的。不幸的是,您的自制協議很容易受到XSRF /會話固定攻擊的影響,因爲沒有任何東西阻止我作爲壞人創建指向「https:// other-server.example.com/Account /」的HTML自動發佈表單並且發送我自己的一個令牌。如果受害者訪問我的惡意頁面,他將自動以我自己的帳戶登錄,如果受害者將個人數據發送到您的網站,可能會導致數據泄露。 – Pinpoint
@Pinpoint非常感謝您的評論。這是我沒有考慮到的一個非常有效的觀點。我想這可以通過檢查HTTP Referer頭來緩解,以確保它來源於可靠的來源。無論哪種方式,我都希望您能針對問題提出解決方案。 – Fred
您可以設置一個cookie,然後重定向到一個子域。 這種方法的好處是它可以防止Pinpiont指出的XSRF /會話固定攻擊。缺點是兩個站點都必須駐留在某個域上。
[RequireHttps]
public IActionResult Redirect()
{
var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
const string domain = "subdomain.example.com";
Response.Cookies.Append("token", token, new CookieOptions {
Domain = domain,
Expires = DateTime.Now.AddHours(1),
HttpOnly = true,
Path = new PathString("/Account"),
Secure = true,
});
return Redirect($"https://{domain}/Account");
}
你已經有一個jwt令牌?從哪裏來,爲什麼你不能使用提供該標記的權威機構來驗證它,當你想在你的web-api中使用它時? Identity Server可以直接設置並掛接到您自己的身份提供商,並擁有可供您的受保護資源使用的中間件來驗證完整性 - 如果這是您的需要。 – Mashton
我真的不需要auth,因爲我不會爲客戶提供服務,我是客戶..,我的問題是如何將令牌傳遞給我的請求,在.net核心中這看起來並不簡單所有對我來說,我沒有得到一個新的令牌,我沒有登錄到遠程,我可以使用郵遞員發送請求就好,但是像添加一個標題到一個帖子或獲取,應該更容易在文檔中找到依賴注入的所有東西,但實際上它有時會讓事情變得比他們需要的更困難。 – webdev8183
@ johnny5說「身份服務器4是有史以來最大的痛苦」,甚至沒有提出你的論點聽起來*有點*苛刻,恕我直言。由於IdSrv是一個免費的OSS項目,爲什麼不聯繫項目業主告訴他們「痛點」可以重新修復? – Pinpoint