.NET開発基盤部会」によって運営されています。Connectについて。Provider)に加入する必要がある。Provider)に対しても認証要求を遂行する必要がある。Party(RP)と名称が変更されている。OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。Provider)は、Identifierを使用して認証する。2.0からはXRIというURIを拡張した形式で表されたものを指す。Identifierの暗号化された証明(紹介状)を発行。Provider(OP)とも呼ばれる。Identifier使用するOPが内部的に使用するユーザID。OPがOP上の認証処理等で使用する。用語に関しては、OpenIDと≒。Provider)に加入する必要がある。Providerは更に以下の2つに分類される。中央集権型でない、分散ID認証システムのオープン仕様。ブラウザベースの認証APIの標準化から始まった。Token)を受け取るか?の違いがある。†OpenID財団の登録商標。Token)として、提供元となるIdpが転送するプロトコル。1.1:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。2.0:RP経由で紹介状を作成して送信する公証人OPを呼び出す。Consumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。Token)を渡し、権限付与を行うプロトコル。ユーザが外部サービスにパスワードを教えることなく、サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。削除などのアクセス許可を与える。サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。†OpenIDよりもOAuth認証をしたいというサイトが増えてきている。認証機能は無いとされているので、拡張仕様で、"安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。2.0を拡張し、正しく"認証"する次世代のOpenID。Connectによって置換えられた。Token)相当のコピーだけが入っているロッカーの合鍵を渡す所。Endpointへの合鍵を発行する。800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。金融システムや電子政府/行政システムにも利用できることを意味している。Connectクライアントは、生でも書ける。†コンシューマー向け技術と言える。(REST/JSONベースで、Webアプリケーションに組み込みやすい)。1.0仕様は、同時期に策定された。ユーザから見た画面遷移もほぼ同じ開発者の間で機能が比較された。Token)を渡し、認可する仕組み。認証機能は無いとされているので、拡張仕様で、"安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。2.0を置き換えたもの。1.0の仕様は、同時期に策定された。メリット一度の実装で複数のOPに対応できる。新たなOPが増えた場合もコストをかけずに対応が可能ユーザー認証を実装でき、その上サービス独自のAPIを利用できる。1.0のように、サービス上のAPIに権限を付与する機能はない。1.0の仕様は、同時期に策定された。Tokenを返すことで、(認証+)APIに対する権限付与ができる。Tokenを使用して、プロフィール情報(=クレーム的なもの)を取得できるAPIが提供されれば、認証の処理を実装できる。デメリット認証結果の定義や認証ポリシーの指定方法が存在しない。Serverに追加実装が必要になる。1.0に以下の改良を加えている。2.0の違い」を参照。2.0を置き換えたもの。これまで足りなかった以下のような機能拡張がされている。2.0のリクエストを少し変更するだけで、利用できる。2.0のリクエストパラメータに特定の値を指定するだけ。複数のクライント・フローを実装するのは手間。Idpを開発するのに比べれば、RPを開発する方が楽。800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。金融システムや電子政府/行政システムにも利用できることを意味している。