ID フェデレーションとは?OAuth2.0 と OpenID Connect の関係

スポンサーリンク
セキュリティ

ID フェデレーションについて調べたところ、以下の5点で混乱したので、まとめることにしました。

  • ID フェデレーションって何?
  • ID フェデレーションと SSO の違いって何?
  • OAuth2.0 と OpenID Connect と SAML の違いって何?
  • トークン ID とアクセストークンの違いって何?
  • 結局どうやってフェデレーションするの?

ID フェデレーションとは

ID フェデレーションとは、ユーザーの認証結果を別のサイトで使い回せる技術です。

ID フェデレーションの例

ID フェデレーションを利用すると、上記のように Twitter や Google などの認証(ログイン)結果を自分のサイトでも利用することができます。

ID フェデレーションと SSO(シングルサインオン)の違い

ID フェデレーションは、SSO(シングルサインオン)を実現する方式の1つです。

フェデレーションとは、それぞれ個別に認証機能を持つクラウドやサイト間でのシングルサインオンのことです。

https://www.hpe.com/jp/ja/japan/icewall/federation/overview.html

SSO(シングルサインオン)を実現する方式には次の4種類が存在します。

  • ケルベロス認証方式: ケルベロス認証を利用する
  • エージェント方式: 認証を代行する「エージェント」モジュールを組み込む
  • リバースプロキシ方式: リバースプロキシサーバー + エージェント型
  • フェデレーション方式: ユーザ認証結果を他の認証基盤に渡す(ID フェデレーション)

なお、認証基盤には OpenLDAP や ActiveDirectory を利用します。

OpenLDAP の詳細については以下の記事をご覧ください。

IdP, SP とは

認証結果を「提供する認証基盤」・「利用する認証基盤」にはそれぞれ以下の名前がついています。

  • Identity Provider (IdP): SP に認証結果を提供する認証基盤
  • Service Provider (SP): IdP から受け取った認証結果を利用する認証基盤

認可と認証の違い

認可と認証はよく似た言葉ですが、意味が異なるので注意してください。

認可(Authorization・AuthZ)認証(Authentication・AuthN)
目的権限を付与
ユーザーを識別および検証
利用例マイページの閲覧権限に利用ログインに利用
具体例

ID フェデレーションの仕組み

ID フェデレーションでは、認証結果を別の認証基盤に伝送することで、ログインの使いまわしを実現します。

認証結果を別の認証基盤に伝送する方法は次の2種類です。

  • SAML
  • OpenID Connect

SAML と OpenID Connect の違い

SAML と OpenID Connect の違いは以下のとおりです。

SAMLOpenID Connect
認証結果の伝送方法アサーション(後述)ID トークン(後述)
データ形式XMLJSON
普及率オワコン(と言われながら多くの企業で利用)次世代のスタンダード

SAML とは

SAML とは、以下の2つの機能から構成されます。
認証属性権限の認可XMLで表現する機能
・上記の XML を伝送する機能

アサーションとは

アサーションとは、認証、属性、権限の認可をXMLで表したものです。

  • 認証ステートメント(Authentication statements)
    • 認証情報に関するステートメント
    • 認証時刻や認証が行われた場所などの情報を含む[7]
  • 属性ステートメント(Attribute statements):
    • サブジェクト(認証、認可する対象)の属性に関するステートメント[7]
    • サブジェクトの名前、年齢、性別、ゴールドカードの保持者[7]である等
  • 認可決定ステートメント(Authorization decision statements):
    • サブジェクトの認可(権限)に関するステートメント[7]
    • 特定のファイルへのアクセス権限や、特定の品物を買う事ができる権限[7]など

OpenID Connect と OAuth2.0 とは

OpenID の種類には以下の2つがあります。

  • OpenID Authentication 2.0(OAuth 2.0)= 認可機能
  • OpenID Connect(OIDC)= OAuth2.0 に認証機能を加えたもの

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

https://openid.net/connect/

OpenID Connect と OAuth2.0 の違い

OAuth2.0 と OIDC の機能の比較は以下のとおりです。OIDC の拡張仕様は赤線で引いています。

OAuth2.0
(OpenID Authentication 2.0)
OIDC
(OpenID Connect)
目的Service Provider に権限を与えるService Provider に権限を与える
Service Provider に他の認証基盤で利用可能な認証結果を与える
機能認可(Authorization = AuthZ)認可(Authorization = AuthZ)
認証(Authentication = AuthN)
具体例
動作認可サーバーからアクセストークンを取得認可サーバーからアクセストークンを取得
Identity Provider からID トークンを取得

OAuth2.0 は認可(Authorization)サーバーの役割を持ちますが、認証(Authentication)サーバーの役割は仕様範囲外です。

OAuth defines four roles:

  • resource owner
  • resource server
  • client
  • authorization server

The interaction between the authorization server and resource server is beyond the scope of this specification.

https://tools.ietf.org/html/rfc6749#section-1.1

ID トークンの詳細

ID フェデレーションでは、ID トークンを利用してユーザーを認証します。

OIDC 標準に従った ID トークンの中身は以下の通りです。

Final: OpenID Connect Core 1.0 incorporating errata set 1
OpenID Connect Core 1.0 incorporating errata set 1

ID フェデレーションの実装

OIDC を利用して ID フェデレーションを実際に実装してみます。

  • ID トークンを利用して ID フェデレーションでログイン
  • ログインした後は、アクセストークンで指定した Federated Identity の権限を持つ

今回の例では、Cognito で作成したログイン画面で Amazon QuickSight に ID フェデレーションをします。

aws-samples/aws-cognito-quicksight-auth
A simple JavaScript frontend and SAM template to spin up a serverless backend, federating Cognito User Pools users to QuickSight as part of the blog post:

Github の説明でデプロイ方法がわからない人は、以下の記事がわかりやすいので参照してください。

CognitoのユーザーでQuickSightログインを試してみる | Developers.IO
aws-samplesにCognitoユーザーでQuickSightにログインするシステムのサンプルが公開されていたので試してみました。

ちなみに、S3 バケットポリシーのブロックパブリックが ON になってると CloudFormation でエラーがでたので注意してください。

デプロイ後の構成

  1. ログインし、Cognito ユーザープールから ID トークンを入手
  2. ID トークンを利用して Cognito ID Pool から IAM Role のアクセストークンを入手
  3. Signin Token を入手するために API Gateway にリクエストを送信
  4. getSigninTokenリクエストを送信
    • IAM Role のアクセストークンを渡す
  5. SigninToken を Service Provider(コールバック URL)に返却
  6. SigninToken を付与した login リクエストを送信
  7. QSにログイン成功
    • アクセストークンで指定した IAM Role の権限を持つ

参考資料

OAuth 2.0 + OpenID Connect をフルスクラッチした人の記事です。とてもわかりやすいので読みましょう。

一番分かりやすい OpenID Connect の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OpenID Connect(オープンアイディー・コネクト)の説明を繰り返してきました※1。 その結果、OpenID Connect をかなり分かりやすく説明することができるようにな...
一番分かりやすい OAuth の説明 - Qiita
はじめに 過去三年間、技術者ではない方々に OAuth(オーオース)の説明を繰り返してきました※1,※2。その結果、OAuth をかなり分かりやすく説明することができるようになりました。この記事では、その説明手順をご紹介します...
0

コメント