2
auth-schemeに関する質問があります。私は、JSONウェブトークンに遭遇し、公式ページの1：HTTPでの認証方式の目的認証ヘッダー
彼らは私がAuthorization: JWT <token>に精通していますし、それが今日まで正しかったと仮定していたが、過去には
Authorization: Bearer <token>
を使用し、私は公式のJWTウェブページを読んで、代わりにBearer <token>を使いました。
私も取り除くことができます：https://github.com/nsarno/knockをし、このライブラリで、私はランダムのauth-スキームと私のRailsのAPIへの郵便配達依頼を作ることができた：
私はノックRailsの宝石をテストしていました完全AUTH-スキーム：私はAuthorizationヘッダーから自分JWTトークンを削除
が、しかし、それはeと401不正な応答を返します私はそれが...働いていることを知っていますか？
だから私は...のauth-スキームに目的があると思うようになりましたか？
Authorizationヘッダーのauth-schemeの正しい使用法を尊重し、尊重し、遵守すると考えていますか？
私は答えのための私の探求でこのStackOverflowのポストに出くわした：
Custom HTTP Authorization Header
それは公式の形式は示した：
credentials = auth-scheme #auth-param
与えられた例はさらに奇妙だった：
Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="
これが次の条件を満たすかどうかわかりませんプログラミングの質問。私は盲目的に第三者図書館に従う/使用することができます。
auth-schemeの目的は何ですか？
私は暗号化/コンピュータセキュリティの専門家ではありません。
多分誰かがこの問題（または問題ではないかもしれませんか？
はい、auth-schemeは、サーバーに次のトークンが何であるかを伝えることです。それはむしろ明らかです。より重要な質問は、サーバーがそれを強制すべきかどうかです。 – Zhang
@Zhangサーバーが認証としてJWTトークンを受け取るだけであれば、認証スキームの識別子を許して無視することができます。しかし、サーバーが複数の認証スキームをサポートしている場合、それに続くものを伝えるために識別子が必要です。 – MvdD
音が分かりやすい:)サーバーが受信したトークンで認証方式を強制しないと、セキュリティ上の問題が将来発生するかどうかという懸念があると思います。 – Zhang