自定義授權標頭

Question

我知道Stack Overflow上有足夠的內容可以解決這個問題，但我的主題與其他主題不同。 （有點相同但不相等）

我想聽聽社區對我所做的事情的看法，看看我是否可以在某處改進。

我目前正在為我的登錄EndPoint使用BASIC授權，因為它不需要復雜性，而且它的https非常好，所以它很好。

例：

GET - / api / login

授權：基本BASE64String（用戶名：密碼）

我的一些EndPoints要求令牌被授予對資源的訪問權限。 這些令牌我通過Headers和Https-Secured發送。

問題是我沒有使用傳統方法來執行這些授權。 以下是一些例子：

例1：

GET - / api / hardware / {PUBLIC_TOKEN} / getMe

授權 - 硬件： PRIVATE_TOKEN

此EndPoint不需要授權 - 硬件標頭，但如果包含更多內容則由API完成。 （這里不相關）

例2：

GET - / api / login / {id}

授權人： USER_TOKEN

否則，此EndPoint是必需的，包括具有用戶令牌的授權人頭，以訪問資源。 （請注意，生成令牌的方式與此無關）

要訪問API EndPoints，必須提供HTTPS請求。

我給上面的自定義標題和EndPoints提供了任意名稱，只是為了說明我的授權模式是什么，名稱與原始名稱不匹配。 所以不要打擾模式上的foccus名稱。

我的問題是：不遵循對流方式是一件壞事嗎？ 創建自定義授權標題是不好的（如果這是為什么？）。

我發現這種方式更簡單，可以提供授權和傳遞令牌的安全方式，所有這些令牌都可以再次在平台中重新生成。

許多設備和移動應用程序已經在使用這個Schema，但它全部都在開發環境下，而且還沒有生產。 我擔心這種非傳統的方式可能會影響API的用戶。 希望社區的想法可以幫助我改善這一點。

編輯：26/03/2017

我想知道它是否會更好以及為什么以協議中描述的方式實現，因為當需要多個授權時比在有自定義標頭並且想要檢索其值時更難從Header獲取。

遵循協議，您應該使用授權標頭，如下所示：

Authorization: <type> <value>

例：

GET - / api / login / {id}

授權：用戶USER_TOKEN

但是我無法看到我在這之后得到的東西，因為當獲取它的值時會出現一個String或者在示例中它會返回User Token。

使用自定義標頭更容易驗證令牌。 多種授權也會在協議方式下令人頭疼。

Answer 1

TL; DR一些頭文件名，例如Authorization有關於緩存以及代理和客戶端處理的特殊規則; 除非您修改了每個代理和客戶端，否則您的自定義標題名稱不會獲得特殊行為。

使用RFC7234中定義的公共Authorization: <type> <value>標頭主要是為了確保本機實現這些標頭處理的客戶端和HTTP代理的行為正確。

RFC7234的4.2節說：

轉發請求的代理不得修改該請求中的任何授權字段。 有關HTTP緩存處理授權字段的詳細信息和要求，請參見[RFC7234]的第3.2節。

代理可以修改，省略，記錄或緩存您的其他Authorization-*標頭。

RFC7234，第3.2節說，請求/響應Authorization頭不得緩存（特定情況除外）。

RFC7235，第5.1.2節，第7點還說明了使用Authorization以外的標頭的新身份驗證方案：

因此，通過強制使用Cache-Control請求指令（例如，“no-存儲“，[RFC7234]的第5.2.1.5節）或響應指令（例如，”私有“）。

那你該怎么辦...？ 如果控制器完全系統的兩端，這是不是不合理的定義可能有多個參數來覆蓋一個或多個令牌類型的任意組合一個新的類型值，就避免了,性格：

Authorization: MyAuth User=USER_TOKEN/Hardware=HWTOKEN/Person=PERSONTOKEN/Basic=...

替代取決於服務器和客戶端的實現更多，並且將被使用,作為多個標頭的替代版本列表的形式：

Authorization: User USER_TOKEN, Hardware=HWTOKEN, Person=PERSONTOKEN, Basic=...

根據服務器和客戶端的不同，可能會被視為：

Authorization: User USER_TOKEN
Authorization: Hardware HWTOKEN
Authorization: Person PERSONTOKEN
Authorization: Basic ...

這里的問題是“ MAY ”（許多額外的重點）被視為相同。 有討論的建議是，各種版本的Apache和NGINX都不會對此進行一致的處理，並且舊的HTTP RFC對於預期的行為非常不清楚。