簡體   English   中英

使用Auth0授權來自我們的SPA和我們的其他后端服務的API請求

[英]Using Auth0 to Authorize API requests from both our SPA and our other back-end services

我們有一個單頁應用程序,它調用我們的后端服務(C#和Python),使用Auth0 SPA流程授權這些請求。

我們的后端服務僅作為處理來自SPA用戶的請求的一部分向對方發出請求,因此目前我們只是從SPA請求轉發Authorization標頭,使用它來授權對每個被調用服務的操作。

我現在想要添加后端處理作業,這些作業將在我們的服務之間發出請求,從而調用現有的端點。 這些請求將不會有任何現有的auth標頭轉發,因此需要構建自己的。

基於Auth0文檔, 在這里這里 ,我相信我應該使用客戶端憑據授權來授權這些請求,並且我推斷我們現有的端點因此需要接受以兩種不同方式授權的請求:來自SPA或來自其他服務。

問題是來自SPA的JWT使用一個密鑰簽名,而來自服務的JWT使用它們各自的密鑰簽名。 我是對的,我需要配置我的端點,以便他們接受使用任何這些秘密密鑰構建的JWT?

所以我的核心問題是 :這種理解是正確的,還是我應該以完全不同的方式做到這一點?

細節:

我們的端點需要處理的兩種類型的授權JWT令牌是:

1來自SPA的要求,包含:

sub: SPA-USER-ID
aud: SPA-CLIENT-ID

使用我們SPA的客戶密碼使用HS256(歷史原因)簽名。

2服務到服務請求,包含:

sub: SERVICE-ID@clients
aud: API-ID
scope: ""

使用我們的呼叫服務的客戶端密鑰使用HS256(現在為了簡單起見)簽名。

如果一個端點要解碼並驗證兩個請求,首先它會失敗,因為'aud'值是不同的。 我認為現有SPA調用的'aud'值是一個錯誤 - 它應該是接收請求的API的ID。 然后兩個請求中的'aud'值將是相同的。

下一個區別是它們每個都使用不同的密鑰簽名 - SPA或呼叫服務(如果我選擇使用RS256作為Auth0推薦的新服務呼叫,也可能使用不同的算法)。

我無法發現明顯的方法來修改Python和C#快速入門以接受使用不同鍵編碼的令牌。 我正在考慮自己編碼,手動嘗試一個,如果失敗則嘗試另一個。 我有信心我可以為Python端點授權做這件事,我自己編寫了基於使用PyJWT的Auth0快速入門,但不太熟悉我們的C#內容,它也基於Auth0快速入門,但似乎使用了一些內置.NET JWT驗證中間件,我完全不確定我可以在其內部添加上述功能。

但如果我以正確的方式這樣做,那么這肯定是一個常見的要求嗎?

抱歉,如果這個問題形成不好,我對auth一無所知,並且正在閱讀Auth0 / Oath2文檔,以便在我去的時候弄明白。

(以第三人稱回答我自己的問題)

這種理解是正確的,還是我應該以完全不同的方式做到這一點?

問題中概述的整體流程是正確的。 然而,有一個普遍存在的誤解:

當服務(或SPA)從Auth0(或任何發行者)請求新訪問令牌時,他們提供的密鑰通常不是Auth0用於簽署返回令牌的密鑰。 相反,發行者使用受眾的密鑰(將使用此訪問令牌調用的API)。

OP之所以對此感到困惑,是因為他所繼承的代碼,如問題所述,在請求令牌時錯誤地傳遞了SPA本身的“受眾”價值。 因此,使用SPA的秘密簽署所產生的令牌。 修復此問題后,要將API ID用作“受眾”,則為SPA生成的令牌和為服務到服務調用生成的令牌將全部:

  1. 包含audience = API-ID,因此除了'sub'(用戶id)和'scope'(當前未使用)之外,將包含所有方面的等效有效負載。

  2. 使用觀眾的API-SECRET與HS256簽約。

因此,端點不必檢查使用兩個不同密鑰編碼的兩種不同類型的令牌。 它可以使用它自己的“受眾”標識符和自己的密鑰來檢查傳入的請求,這將成功解碼和驗證來自SPA和其他服務的請求。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM