OAuth 2仕様のリソース所有者とパスワードの認証情報フローを実装しようとしています。token_type有効な応答で返される値を理解できません。仕様ではすべての例が示されて"token_type":"example"いますが、
token_typeは必須です。セクション7.1の説明に従って発行されたトークンのタイプ 。値は大文字と小文字を区別しません。
誰かがこれを私に説明してくれませんか？
OAuth 2仕様のリソース所有者とパスワードの認証情報フローを実装しようとしています。token_type有効な応答で返される値を理解できません。仕様ではすべての例が示されて"token_type":"example"いますが、
token_typeは必須です。セクション7.1の説明に従って発行されたトークンのタイプ 。値は大文字と小文字を区別しません。
誰かがこれを私に説明してくれませんか？
回答:
token_typeは、Authorizationサーバーへのアクセストークン生成呼び出しのパラメーターです。これは、リソースアクセス呼び出しに対してaccess_tokenがどのように生成および提示されるかを本質的に表します。認可サーバーへのアクセストークン生成呼び出しでtoken_typeを指定します。
あなたが与える場合Bearer（ほとんどの実装上のデフォルト）、access_token生成され、あなたに戻って送信されます。ベアラーは、「このトークンのベアラーへのアクセスを許可する」と簡単に理解できます。1つの有効なトークンと質問はありません。一方、Macand sign_type（hmac-sha-1ほとんどの実装ではデフォルト）を選択すると、アクセストークンが生成され、Key Managerに属性として秘密として保持され、暗号化された秘密が次のように送信されます。access_token
はい、独自のの実装を使用できますがtoken_type、開発者はOAuthの標準の実装ではなくプロセスに従う必要があるため、あまり意味がありません。
誰でも「token_type」をOAuth 2.0拡張機能として定義できますが、現在「ベアラー」トークンタイプが最も一般的です。
https://tools.ietf.org/html/rfc6750
基本的にそれはFacebookが使用しているものです。ただし、その実装は最新の仕様から少し遅れています。
Facebookよりも安全にしたい場合（または「署名」を持つOAuth 1.0と同じくらい安全にしたい場合）、「mac」トークンタイプを使用できます。
ただし、Macの仕様はまだ急速に変化しているため、難しい方法です。
ベアラートークン
トークンを所持するすべての当事者（「ベアラー」）が、トークンを所持する他の当事者が使用できる方法でトークンを使用できるという特性を持つセキュリティトークン。ベアラートークンを使用する場合、ベアラーは暗号鍵素材（所有証明）の所有を証明する必要はありません。
Bearer TokenまたはRefreshトークンは、認証サーバーによって作成されます。ユーザーがアプリケーション（クライアント）を認証すると、認証サーバーは、ベアラートークン（更新トークン）を生成します。これを使用して、アクセストークンを取得できます。
Bearer Tokenは通常、認証サーバーによって作成されるある種の不可解な値であり、アクセスを許可するユーザーとアプリケーションがアクセスを取得するクライアントに基づいてランダムに作成されるものではありません。