.NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。クレームベース認証)。[#l4dc0ed8]-IDの一元管理--アプリ側に重複したユーザストアを持たせない。された、最新のIDを利用する。-SSO(シングルサインオン)--パスワードをユーザに分散管理させたくない。--クラウド上のサービスを自社内で認証したい。--コンシューマー向けアプリをSNS認証で利用させたい。Connect>#bd876705]]など、~大体、認証後に発行するトークン(クレーム)的なものを使用して認可(認証)する仕掛けになっている。Provider)が行う。Service)が行う。トークンにパッケージ化される。Provider)が行う。Service)が発行する~トークン(クレーム)的なものにより、認証(Idp)と認可/認証(SP)を分離できる。-分散型の認証方式を提供するオープンな認証システムと言える~(これを世の中では[[認証連携(IDフェデレーション)>#i5c2d8e8]]と呼んでいる)。-OAuthに関しては、トークンとクレームの発行が分離されている。~トークン発行までがOAuthの仕様なので、認証用のクレーム発行は拡張仕様を実装する必要がある。[#h4a44b62]各用語については下記を参照。[#d20b62f2]フェデレーションは、「連携」の意味。-[[SAML]]、OpenIDなどの認証・認可に関わるプロトコルやその仕組みの総称として使われることがある。Party)の2つに役割を分担する。間でユーザーアカウントを紐付けることを意味する。信頼関係を結んだ後、アカウント連携を行う必要がある。[#secb0045]それによって、以下の様な利点が発生する。-サービス・プロバイダ側で直接認証(IDやパスワードの入力)を行っていない。サービス・プロバイダへのネットワーク経路上をパスワードが流れない。-サービス・プロバイダが直接アイデンティティ・プロバイダと通信を行っていない。アイデンティティ・プロバイダとサービス・プロバイダは別々のネットワークに存在してもよい。~イントラネット上のアイデンティティ・プロバイダを利用して、--クラウド上のサービス・プロバイダへセキュアなアクセスを行うといったことが可能になり、~--イントラネット上の社内アプリケーションにも同様の仕組みを導入することにより、~セキュアなシングル・サインオンという非常に利便性の高いシステムを構築できる。[#c536655a]-プログラムの前提として満たされるべき条件を記述するもの。-IdP/STSが発行する認証・認可の情報(認証情報やユーザーや属性、アクセス権限等の情報)。-[[SAML]]や[[JWT]]などのフォーマットが使用される。Foundation)に関連する用語。Provider)に加入する必要がある。Provider)に対しても認証要求を遂行する必要がある。Party(RP)と名称が変更されている。~OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。Provider)は、Identifierを使用して認証する。2.0};からはXRIというURIを拡張した形式で表されたものを指す。Identifierの暗号化された証明(紹介状)を発行。Provider(OP)とも呼ばれる。Identifier---使用するOPが内部的に使用するユーザID。---OPがOP上の認証処理等で使用する。[#qa5b24ca]用語に関しては、[[OpenID]]と≒。Server)に加入する必要がある。Providerは更に以下の2つに分類される。2.0の用語>#w507f337]]を使用する(ただし実装は、OAuthの拡張)。[#j361796e]-認証連携(IDフェデレーション)プロトコル-異なるベンダのアクセス制御製品間の相互運用性を推進し、~企業間の独立したサービスをグローバルなSSOで連携させることが可能。-各種の[[STS系ミドルウェア]]でサポートされている。[#sa6cf928]-クッキー認証チケットを使用しない。--クッキーを第三者が不正使用してなりすましを許す可能性がある。--クッキーはクッキードメインの中でしか有効ではない。Assertionsを使用。--以下のプロファイルがある。[#bd876705]中央集権型でない、分散ID認証システムのオープン仕様。-ブラウザベースの認証APIの標準化から始まった。Token)を受け取るか?>の違いがある。Token)として、提供元となるIdpが転送するプロトコル。1.1:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。2.0};:RP経由で紹介状を作成して送信する公証人OPを呼び出す。-[[OpenID]]の仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、~特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。Token)を渡し、権限付与を行うプロトコル。-ユーザが外部サービスにパスワードを教えることなく、~サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。--エンドユーザはサービスAに対してあるサービスB上のリソースや機能に~取得/追加/更新/削除などのアクセス許可を与える。--サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。-[[OpenID]]よりもOAuth認証をしたいというサイトが増えてきている。~ただし、認証機能は無いとされているので、拡張仕様で、~"安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。2.0を拡張し、正しく認証する次世代のOpenID。Connect]]によって置換えられた。Token)のコピーだけが入っているロッカーの鍵を渡す所。Provider)はこの鍵の発行者を信頼し、鍵の正統性の検証が可能。800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。~金融システムや電子政府/行政システムにも利用できることを意味している。[#q3c0e8d6]-色々ある。[#tf6b40d2]エンタープライズにフォーカスした技術と言える(SOAP/XMLベース)。[#h2bbea7c]コンシューマー向け技術と言える。~(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の違い>OAuth#s44d10cb]]」を参照。2.0を置き換えたもの。--これまで足りなかった以下のような機能拡張がされている。2.0のリクエストを少し変更するだけで、利用できる。2.0のリクエストパラメータに特定の値を指定するだけ。--複数のクライント・フローを実装するのは手間。~しかし、Idpを開発するのに比べれば、RPを開発する方が楽。800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。--金融システムや電子政府/行政システムにも利用できることを意味している。