マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

OpenID / OAuth / OpenID Connectについて。

用語

OpenID

  • End User
    • Consumerに対して自分のIdentityの認証を要求しようとするユーザ
    • Consumerに紹介状(OpenID Token)を送るIdP(Identify Provider)に加入する必要がある。
  • User-Agent
    • End Userが所有するWebブラウザ
    • 特別なプラグインやJavaScriptは不要
  • Consumer
    • End Userが入力したID(Identifier)を使用し、IdP(Identify Provider)に対して認証要求するWebサービス
    • ConsumerはいずれのIdP(Identify Provider)に対しても認証要求を遂行する必要がある。
    • OpenID 2.0からはRelying Party(RP)と名称が変更されている。
      OpenIDでは、STS相当が独立しておらず、当該機能がRPとIdp内に同梱されている。
  • Identifier
    • End Userが所有するURL(httpまたはhttpsをschemeとするURI)
    • IdP(Identify Provider)は、Identifierを使用して認証する。
    • OpenID 2.0からはXRIというURIを拡張した形式で表されたものを指す。
  • Claimed Identifier
    • End Userが自分で所有していると主張するIdentifier
    • Consumerによってまだ確認されていないIdentifier
  • Verified Identifier
    ConsumerがEnd Userが所有していると認めたIdentifier
  • User-Supplied Identifier
    OpenID 2.0からの用語で、
    • End UserによってRPに対して提示されるIdentifier
    • Claimed IdentifierまたはOP Identifierの総称
  • Identify Provider(Idp)
    • End Userが所有するClaimed Identifierの暗号化された証明(紹介状)を発行。
    • OpenID 2.0からはOpenID Provider(OP)とも呼ばれる。
  • OpenID 2.0から追加されたOpenID Provider(OP)用語
  • OP Identifier
    OPを表すIdentifier
  • OP EndPoint? URL
    OPのエンドポイントのURL
  • OP-Local Identifier
    • 使用するOPが内部的に使用するユーザID。
    • OPがOP上の認証処理等で使用する。

OAuth

用語に関しては、OpenIDと≒。

  • Resource Owner (OAuth 1.0では、User)
    • Clientにアクセス権限の付与を行うユーザ自身
    • ClientにAccess Tokenを送るAuthorization Server
      OAuth 1.0では、OAuth Service Provider)に加入する必要がある。
  • User-Agent
    • End Userが所有するWebブラウザ
    • 特別なプラグインやJavaScriptは不要
  • OAuth Client (OAuth 1.0では、OAuth Consumer)
    OAuth Serverが提供するAPIを利用する側のサービス
    • Instagram
    • Foursquare
    • Pinterest
  • OAuth Server (OAuth 1.0では、OAuth Service Provider)
  • OAuthをサポートしたAPIを提供しているサービス
    • Twitter (1.0)
    • Facebook
  • OAuth2.0から)OAuth Service Providerは更に以下の2つに分類される。
    • Authorization Server
      認証・認可のサーバー機能(認証チケットとAccess Tokenの発行)
    • Resource Server
      Access Tokenを受けてリソースアクセスを提供する

OpenID Connect

Financial API (FAPI)

・・・

詳細

中央集権型でない、分散ID認証システムのオープン仕様。

  • ブラウザベースの認証APIの標準化から始まった。
  • トークン(クレーム)として、
  • OpenID
    紹介状(OpenID Token)を受け取るか?

の違いがある。

OpenID

OpenID財団の登録商標。

代表的な使用例として、

  • OpenID Authentication 2.0
  • OpenID Connect
  • OpenID Foundation

などがあるが、

ここでは、OpenID Authentication 1.1, 2.0を指す。

要求元であるWebサイトに対して、

  • あるユーザが認証された旨の情報、
  • 認証をどのように行ったかの情報、
  • 当該ユーザの属性情報を、

紹介状(OpenID Token)として、提供元となるIdpが転送するプロトコル。

  • OpenID 1.1:Consumer経由で紹介状を作成して送信する公証人Idpを呼び出す。
  • OpenID 2.0:RP経由で紹介状を作成して送信する公証人OPを呼び出す。
  • OpenIDの仕様上、誰でもConsumer(RP)やIdp(OP)になれるという点から、
    特にConsumer(RP)はどのIdp(OP)を信用したらよいかという問題が残る。

OAuth

概要

  • 紹介状(OpenID Token)ではなく、合鍵(Bearer Token)を渡し、権限付与を行うプロトコル。
  • ユーザが外部サービスにパスワードを教えることなく、
    サービス間でユーザの同意のもとにセキュアにユーザの権限情報(合鍵)を受け渡しする。
  • エンドユーザはサービスAに対してあるサービスB上のリソースや機能に
    取得 / 追加 / 更新 / 削除などのアクセス許可を与える。
  • サービスAは、エンドユーザの許可を受けたサービスB上のリソースや機能にアクセスする。

問題点

  • OpenIDよりもOAuth認証をしたいというサイトが増えてきている。
  • しかし、認証機能は無いとされているので、拡張仕様で、
    "安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。

OpenID Connect

概要

  • OpenID Authentication 2.0 のプロトコルを引き継ぐことをせず、
    OAuth 2.0を拡張し、正しく"認証"する次世代のOpenID。
  • OpenID Authentication 2.0 の"認証"は、OpenID Connectによって置換えられた。
  • サイトにアクセスする方法はOAuth 2.0 の Resource Access と同じ。
  • OAuth 2.0 ベース
    OpenID Authentication 2.0との違いは、
    紹介状(OpenID Token)相当のコピーだけが入っているロッカーの合鍵を渡す所。
    • ロッカー:UserInfo? (ユーザ情報)Endpoint
    • 合鍵:UserInfo? Endpointへの合鍵を発行する。
    • ClientとResource Serverは、
      • この合鍵の発行者を信頼し、
      • 合鍵の正統性の検証が可能。

設計思想

  • モジュラーデザイン
  • 簡単なことは簡単に
  • 難しいことも可能に
  • NIST SP 800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。
    金融システムや電子政府/行政システムにも利用できることを意味している。

Financial API (FAPI)

金融機関API向けJSON data schema, REST APIの、
セキュリティ+プライバシー・プロファイルの勧告(チェックリスト)を提供

その他

ライブラリ

  • 色々ある。
    • Azure AD 認証ライブラリ (ADAL)
    • Azure AD v2.0 認証ライブラリ (MSAL)

STS系ミドルウェア

選定

コンシューマー向け技術と言える。
(REST/JSONベースで、Webアプリケーションに組み込みやすい)。

  • OpenID 2.0とOAuth 1.0
    • 仕様は、同時期に策定された。
    • ユーザから見た画面遷移もほぼ同じ
    • 開発者の間で機能が比較された。
  • OAuth 2.0
    • 合鍵(Bearer Token)を渡し、認可する仕組み。
    • 認証機能は無いとされているので、拡張仕様で、
      "安全な"紹介状(クレーム)を発行する仕組みを追加で作り込む必要がある。
  • OpenID Connect
    OAuth 2.0を拡張して、OpenID 2.0を置き換えたもの。

OpenID

  • OpenID 2.0 (OAuthとの比較)
    OpenID 2.0とOAuth 1.0の仕様は、同時期に策定された。
  • メリット
    • 一度の実装で複数のOPに対応できる。
    • 新たなOPが増えた場合もコストをかけずに対応が可能
    • ユーザー認証を実装でき、その上サービス独自のAPIを利用できる。
  • デメリット
    • OAuth 1.0のように、サービス上のAPIに権限を付与する機能はない。

OAuth

  • OAuth 1.0 (OpenIDとの比較)
    OpenID 2.0とOAuth 1.0の仕様は、同時期に策定された。
  • メリット
    • Access Tokenを返すことで、(認証+)APIに対する権限付与ができる。
    • 上記のAccess Tokenを使用して、プロフィール情報(=クレーム的なもの)
      を取得できるAPIが提供されれば、認証の処理を実装できる。
  • デメリット
    • 認証結果の定義や認証ポリシーの指定方法が存在しない。
    • 従って、OAuth の Clientと、Resources Serverに追加実装が必要になる。
  • OAuth 2.0
    OAuth 1.0に以下の改良を加えている。
    • HTTPSを必須にし、署名をなくし、Access Token取得も簡略化
    • Request Tokenを無くし、Access Tokenのみでリソース取得が可能に
    • Webアプリも含め、4つのクライアントプロファイルを仕様化
    • 詳しくは「OAuth 1.0とOAuth 2.0の違い」を参照。

OpenID Connect

次世代OpenID

  • OpenID 2.0のプロトコルを引き継ぐことをせず、
    OAuth 2.0を拡張して、OpenID 2.0を置き換えたもの。
  • これまで足りなかった以下のような機能拡張がされている。
    • 認証結果のやりとり
    • 統一的な属性情報の提供
    • OP探索、動的なRP登録
    • RPに戻った後のセッション管理
  • 実装(RP)
    • RPはOAuth 2.0のリクエストを少し変更するだけで、利用できる。
      OAuth 2.0のリクエストパラメータに特定の値を指定するだけ。
    • 複数のクライント・フローを実装するのは手間。
      しかし、Idpを開発するのに比べれば、RPを開発する方が楽。
  • 用途
    • NIST SP 800-63-1で定義されている全ユーザ認証要件(LoA)への対応が可能。
    • 金融システムや電子政府/行政システムにも利用できることを意味している。

Financial API (FAPI)

金融機関APIのJSON data schema, REST APIで利用。

課題解決

参考

用語

歴史的背景

TakahikoKawasaki? - Qiita

http://qiita.com/TakahikoKawasaki

Identity | @_Nat Zone

http://www.sakimura.org/category/identity/

Nov Matake

デジタル・アイデンティティ技術最新動向

OAuth 2.0, OpenID ConnectのParameterとFlowの関係


Tags: :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-05-30 (水) 10:36:37 (23d)