OAuth 2.0との比較
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/06 15:46 UTC 版)
「User-Managed Access」の記事における「OAuth 2.0との比較」の解説
次の図では、UMAがOAuth 2.0に追加した点を強調してある。 典型的なOAuthフローにおいて、クライアントアプリケーションを運用している人間であるRO(Resource Owner)は、ログインするためにAS(Authorization Server)にリダイレクトされ、クライアントアプリケーションが機能としてROの代わりにRS(Resource Server)の一定範囲にアクセスできるようにアクセストークンの発行に承諾する。RSとASは、一般的に同一のセキュリティドメイン内で運用されており、それらの間の通信は、OAuthの主仕様によっては標準化されていない。 UMAは、3つの主要コンセプトと対応する構造とフローを追加する。 UMAは、ASにおいてRSがしゃべりかける標準化されたAPI(protection APIと呼ばれるもの)を定義する。このことは、複数のRSがひとつのASと通信できるようにし、その逆もできるようにし、そのAPI自体がOAuthによってセキュアになっているのでペアの間にフォーマルな信頼を確立できるようにする。これはまた、ASがROに対して中心となるユーザインタフェイスを提供できるようにする。 UMAは、ROからは自律的なアクセス要求者(RqP:Requesting Party)を正式に定義する。 これはparty-to-party間の共有やアクセス認可の代理を可能にする。ROは、トークン発行をランタイムに承諾する必要がなく、ポリシーをASに設定することができ、RqPがいつでもアクセスを試みられるようにする。 UMAは、アクセス要求者の信頼度(の格上げのプロセス)に基づいて、認可データと関連付けられたアクセストークンを発行できるようなアクセスのしくみを可能にし、例えば、アクセス要求者からアイデンティティクレームもしくは他のクレームを収集することを可能にする。
※この「OAuth 2.0との比較」の解説は、「User-Managed Access」の解説の一部です。
「OAuth 2.0との比較」を含む「User-Managed Access」の記事については、「User-Managed Access」の概要を参照ください。
- OAuth 2.0との比較のページへのリンク