Token)をレスポンス。Serverにアクセスする。Assertion>#n8fdd9f7]]前者はあまりシナリオに適合していないように思う。7523のサブ仕様>#c65d5829]]の共通部分を抽象化した仕様。Serverを統合するような状況下での利用が想定されている。Ownerとしてのエンド・ユーザの介入を必要としない。Credentialsグラント種別の)代替メカニズム。[#v20f3211]-↓通常、ClientとRPは=では?と思う。-おそらく、Assertionの発行場所を示しているだけで、フロー自体に意味はなさそう。[#vf7e7da7]STSによってアサーションを取得する。[OASIS.WS-Trust]などで利用されている。[#n8fdd9f7]ローカルでアサーションを作成する。[#h34941bb]これを使って[[アクセストークン・リクエスト>#a82c2f7a]]する。Serversは、--一般的に認可付与の短命表現で、~アサーションの有効期間を越えるアクセストークンを発行すべきでない。--アサーション許可要求に応答して---リフレッシュトークンが発行せず、---アクセストークンを短い寿命で発行する。-Clientは、--同じアサーションを使用して新しいアサーションを要求したり、--有効・若しくは新しいアサーションを使用して、~期限切れのアクセストークンをリフレッシュしたり、>できる。Assertions--本仕様に適したタイプのアサーション--アサーションを所有しているすべてのエンティティは、---関連するリソースへのアクセスを取得するために(暗号鍵の所持を証明することなく)アサーションを使用できる。---誤用を防止するために、アサーションは、保管・移送における露見から保護する必要がある。---権限のない当事者にアサーションを漏らさないために、安全な通信チャネルを使用。Assertions--本仕様に適さないタイプのアサーション--アサーションを提示するエンティティは、---関連するリソースにアクセスするには、---追加の暗号資料の所持を証明する必要がある。Server(STS)は、アサーションにキー識別子をバインドする。Serverに示す必要がある。--鍵所有者アサーションシステムのベースラインとして使用することができるが、場合によっては、以下が必要になる。オーディエンスの要件を緩和するため)。[#p574a133]以下のクレームが必要。Connect#ofb73c59]]が参考になる。Server(STS)のIDになる。Assertion>#n8fdd9f7]]の場合、~Audienceの値と同じになる。モデル]]~Audienceの値と同じになる。ID~アサーションの一意の識別子。---他のエンティティが誤って同じ識別子を割り当てないことを保証しなくてはならない。---ワンタイム使用アサーションのメッセージ重複排除を必要とする実装によって使用される可能性がある。Security)が必須。-アサーションの認可付与としての使用を定義。[#eef72461]-クライアント認証なし~urn:ietf:params:oauth:grant-type:*--urn:ietf:params:oauth:grant-type:saml2-bearer--urn:ietf:params:oauth:grant-type:jwt-bearer-クライアント認証あり~既存のフローのクライアント認証を使用する。[#k4e1e004][[RFC7523>#i523cb7d]]のアサーションを参照。[RFC6749]>OAuth#v698197b]]の3.3節に記述されているとおり。-クライアント認証なし~[[Googleの例>#f5ac0fc6]]ではアサーションに同梱させているがRFC中に記述がない。-クライアント認証あり--既存のフローのクライアント認証を使用する。Stringにscopeを指定。[#c3be6c2e]-パラメタに依存するクライアント認証の形式が使用されている場合にのみ必要。[#d6680711]-クライアント認証なし~不要-クライアント認証あり~[[RFC7523>#i523cb7d]]のアサーションを参照。"invalid_grant"エラーコードでなければならない。"error_uri"パラメータを使用して、~アサーションが無効とみなされた理由に関する追加情報を含めることができる。"invalid_client"エラーコードでなければならない。"error_uri"パラメータを使用して、~クライアントのアサーションが無効であると考えられた理由に関する追加情報を含めることができる。7523>#c65d5829]]などを使用すれば、大方問題ない。-その他、--SSL/TLSを使用する。7521>#pae256bf]]のアサーションに[[JWT(JWS)アサーション>#s121ce30]]を使用したもの。[#s121ce30]これを使って[[アクセストークン・リクエスト>#yf148536]]する。claim~トークンを受け入れてはならない前の時間を識別する。-クライアント認証を行う場合、~[[JWT]](JWS)アサーションを使用するが、その仕組み自体は定義されていない。--Subjectにclient_idを設定するという記述がある。--また、[[用例>#xd03a507]]では、クライアントと鍵交換+署名で代替されているもよう。[#f5ac0fc6]-以下、RFCの[[JWT]](JWS)~--よくよく確認すると、---ヘッダが微妙。---scopeをどうやって渡すのか。}-以下、Googleの[[JWT]](JWS)。--よくよく確認すると、---subが無かったりする。---scopeは当然ココだが、RFC中に明記が無い。[#jab8a61d]-[[仕様(7521)のパラメタ>#aed15519]]と同じ。-client_assertionだけ、以下のような注釈有リ。--1つの[[JWT]](JWS)、複数の[[JWT]](JWS)を含んではならない。[#n2b1c5ca][[仕様(7521)のエラー・レスポンス>#u137f3a9]]と同じ。Codeグラント種別>OAuth#yfeb403d]]-[[Implicitグラント種別>OAuth#m5c2d510]]以外に、[[クライアント証明書(pfx形式の電子証明書)>証明書#sd119f77]]を使って、~サービスアカウントで認証する方法がある模様。Libraryに~処理がラッピングされていたため。Libraryの中では、[[JWT]]が使用されている模様。authorizationグラント種別」の用例である模様。Profileであることが明記されている。authorizationグラント種別」をサポートしている模様。Library)>https://docs.microsoft.com/ja-jp/azure/active-directory/develop/active-directory-authentication-libraries]]~にラップされているため[[JWT]]作成処理の詳細などを見ることは出来ない。ベアラーアサーションフローの2つのフローをサポートしている模様。ベアラーアサーションフロー~https://help.salesforce.com/articleView?id=remoteaccess_oauth_SAML_bearer_flow.htm&language=ja&type=0>原理はほぼ同じで、[[SAML]]より[[JWT]]のほうが動作環境的な制約は少ないとのこと。