RFC675 - によると、OAuth 2.0認可フレームワーク:ベアラトークンの使用法では、ベアラトークンは次のとおりです。
トークンを所有しているすべての当事者(「ベアラ」)が、所有している他の当事者が使用できる任意の方法でトークンを使用できるという特性を持つセキュリティートークン。
私にとってこの定義はあいまいであり、私は仕様を見つけることができません。
ご指摘ありがとうございます。
ベアラトークン
トークンを所有しているすべての当事者(「ベアラ」)が、所有している他の当事者が使用できる方法でトークンを使用できるという特性を持つセキュリティトークン。ベアラトークンを使用しても、ベアラが暗号化キーマテリアルの所有(所有証明)を証明する必要はありません。
認証サーバーによって、ベアラトークンまたは更新トークンが自動的に作成されます。ユーザーがアプリケーション(クライアント)を認証すると、認証サーバーはアクセストークンを取得するために使用できるベアラトークン(更新トークン)を生成して生成します。
ベアラトークンは通常、認証サーバによって作成されたある種の秘密の値です。ランダムではありません。それはあなたにアクセス権を与えるユーザーとあなたのアプリケーションにアクセス権を与えるクライアントに基づいて作成されます。
たとえばAPIにアクセスするには、アクセストークンを使用する必要があります。アクセストークンは短命です(約1時間)。新しいアクセストークンを取得するには、ベアラトークンを使用します。アクセストークンを取得するには、認証サーバーにこのベアラトークンをクライアントIDと共に送信します。このようにして、サーバーは、ベアラトークンを使用しているアプリケーションが、ベアラトークンが作成されたアプリケーションと同じアプリケーションであることを認識します。例:私はあなたのアプリケーション用に作成されたベアラトークンを取得し、それを私のアプリケーションで使用することはできません。
Google Refreshトークンは次のようになります。1/mZ1edKKACtPAb7zGlwSzvs72PvhAbGmB8K1ZrGxpcNM
コメントからのコピー:あなたが提供するベアラトークンに制限があるとは思わない。私が考えることができる唯一のことは、そのニースが複数を許可するということです。たとえば、ユーザーはアプリケーションを最大30回認証でき、古いベアラトークンは引き続き機能します。おお、そして、もし6ヶ月のために使われていないなら、私はあなたのシステムからそれを取り除くでしょう。どのようにフォーマットされるかはあなた次第ですので、それらを生成し検証する必要があるのはあなたの認証サーバーです。
更新:
ベアラトークンは、すべてのインラインアクションHTTP要求のAuthorizationヘッダーに設定されています。例えば:
POST /rsvp?eventId=123 HTTP/1.1
Host: events-organizer.com
Authorization: Bearer AbCdEf123456
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/1.0 (KHTML, like Gecko; Gmail Actions)
rsvpStatus=YES
上記の例の文字列"AbCdEf123456"
は、ベアラ許可トークンです。これは認証サーバーによって生成された暗号化トークンです。アクションとともに送信されるすべてのベアラトークンにはissueフィールドがあります。オーディエンスフィールドには送信者ドメインをhttps://の形式のURLとして指定します。たとえば、電子メールが[email protected]からのものである場合、オーディエンスは https://example.com です。
ベアラトークンを使用している場合は、要求が認証サーバから送信されたものであり、送信側ドメイン宛のものであることを確認します。トークンが検証されない場合、サービスはHTTPレスポンスコード401(Unauthorized)でリクエストに応答するべきです。
ベアラトークンはOAuth V2規格の一部であり、多くのAPIで広く採用されています。
私があなたの質問を読んだとき、私は成功せずにインターネット上でベアラトークンがどのように暗号化または署名されているかを探そうとしました。ベアラトークンはハッシュされていない(おそらく部分的ではあるが完全ではない)と思います。その場合、それを復号化してそこからユーザーのプロパティを取得することは不可能だからです。
しかし、あなたの質問はベアラトークンの機能性に関する答えを見つけようとしているようです。
認可プロバイダを実装しているとします。ベアラトークンに任意の種類の文字列を指定できますか?ランダムな文字列にできますか?それはいくつかの属性のbase64エンコーディングである必要がありますか?それはハッシュされるべきですか?
そこで、BearerトークンとRefreshトークンがどのように機能するのかを説明します。
ユーザーがSSLを介してユーザーとパスワードを送信するトークンをユーザーがサーバーに要求すると、サーバーは2つのもの(アクセストークンと更新トークン)を返します。
アクセストークンは、具体的なユーザーとして認証されるためにすべてのリクエストヘッダーに追加する必要があるベアラトークンです。
Authorization: Bearer <access_token>
アクセストークンは、必要なすべてのユーザープロパティ、要求および役割を持つ暗号化された文字列です。 (ロールやクレームを追加すると、トークンのサイズが増加することを確認できます)。リソースサーバーがアクセストークンを受信すると、それを復号化してこれらのユーザープロパティを読み取ることができます。このようにして、ユーザーはすべてのアプリケーションとともに検証され、承認されます。
アクセストークンの有効期限は短い(つまり30分)。アクセストークンの有効期限が長い場合は、理論的には無効にすることはできないため、問題になります。そのため、role = "Admin"で "User"に変わるユーザーを想像してください。ユーザーがrole = "Admin"で古いトークンを保持している場合、彼は管理者権限でトークンの有効期限までアクセスすることができます。アクセストークンの有効期限が短いのはそのためです。
しかし、一つの問題が頭に浮かぶ。アクセストークンの有効期限が短い場合は、短い期間ごとにユーザーとパスワードを送信する必要があります。これは安全ですか?いいえ、違います。避けるべきです。それが、リフレッシュトークンがこの問題を解決するように見えるときです。
更新トークンはDBに格納されており、有効期限が長くなります(例:1か月)。
ユーザーは、更新トークンを使用して、期限切れになると(たとえば、30分ごとに)新しいAccessトークンを取得できます。これは、ユーザーが最初のトークン要求で受け取ったものです。アクセストークンの有効期限が切れると、クライアントは更新トークンを送信する必要があります。この更新トークンがDBに存在する場合、サーバーは新しいアクセストークンと別の更新トークンをクライアントに返します(そして古い更新トークンを新しいものに置き換えます)。
ユーザーのアクセストークンが侵害された場合は、そのユーザーの更新トークンをDBから削除する必要があります。この方法では、ハッカーがリフレッシュトークンを送信する新しいアクセストークンを取得しようとすると、このアクションが拒否されるため、トークンはアクセストークンの有効期限が切れるまで有効になります。
ベアラトークンは、アルファベット、数字、「 - 」、「。」の1回以上の繰り返しです。 、 "_"、 "〜"、 "+"、 "/"の後に0個以上の "="が続きます。
RFC 6750 2.1。認証要求ヘッダーフィールド (フォーマットは ABNF (拡張BNF))
The syntax for Bearer credentials is as follows:
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
これはBase64のように見えますが、 ヘッダー内のトークンをbase64エンコードにする必要がありますか? によると、そうではありません。
"HTTP/1.1、part 7:Authentication" **をもう少し深く掘り下げてみてください。しかし、b64tokenは、base64、base64urlなどで一般的に使用される文字を許可するABNF構文定義にすぎないことがわかります。エンコードまたはデコードを定義するだけでなく、アクセストークンを含むAuthorizationヘッダーの一部に使用できる文字を定義するだけです。