検索
連載

「OpenID Connect」を理解する：デジタル・アイデンティティ技術最新動向（4）（1/2 ページ）

いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。

[ritou，OpenID Foundation Japan] PC用表示 関連情報
Share
Tweet
LINE
Hatena

OpenIDの最新仕様「OpenID Connect」とは

　前回はOpenIDについて振り返りました。続く第4回では、OpenIDの最新仕様として策定が進められている「OpenID Connect」（注1）について、

  • 設計思想
  • 仕様一覧
  • フロー紹介
  • 実装状況と今後

という軸に沿って紹介します。

注1：OpenID Connectの仕様については、OpenID FoundationのConnectワーキンググループ（WG）にて日々議論が行われ、仕様の改修が続いています。仕様策定完了までに内容が変更される可能性があるのでご了承ください。


OpenID Connectの3つの設計思想

　OpenID Connectの設計思想として、次の3点があります。

  • 簡単なことは簡単に
  • 難しいことも可能に
  • モジュラーデザイン

　以下、その設計思想が仕様にどのように反映されているかを簡単に説明します。

簡単なことは簡単に

　OpenIDにおける最低限の要件とは、「OP（OpenID Provider）-RP（Relying Party）間で認証結果と属性情報（クレーム）の受け渡しができること」です。OpenID ConnectはOAuth 2.0をベースとすることで、Webアプリケーションに限らず、さまざまなアプリケーションがこの要件を満たすことを目指しています。

　認証結果のやりとりにはIDトークンという文字列が用いられます。これは、以下の値を含むデータをエンコードして署名を付けたものです。

  • 発行元のOP識別子
  • 発行先のRP識別子（client_id）
  • ユーザー識別子
  • 発行日時

　OAuth 2.0のフローでやりとりされるアクセストークン（Access Token）や認可コード（Authorization Code）とともに、認証結果を表すIDトークンを受け渡すことで、ID連携を可能にしています。

　クレーム提供のためのUserInfoエンドポイントでは、ユーザーの新規登録時に必要なメールアドレス、氏名などの基本的なクレーム一覧が定義されています。

　RP開発者は、これらの機能を利用するためにOpenID Connect独自の新たなリクエストパラメータを覚える必要はありません。OAuth 2.0のリクエストパラメータに特定の値を指定するだけで利用できます。

図1　RPはOAuth 2.0のリクエストを少し変更するだけで、OpenID Connectの機能を利用できる
図1　RPはOAuth 2.0のリクエストを少し変更するだけで、OpenID Connectの機能を利用できる

　仕様全体を通してメッセージ形式にJSONを採用しており、JSONデータから文字列へのエンコード、署名作成、暗号化については、OpenID Connectの仕様と並行して標準化が進められています（注2）。

注2：JSONデータの署名作成（JWS）や暗号化（JWE）の方法は、IETFのJOSE WGにて仕様が策定されています。

Javascript Object Signing and Encryption (jose)

http://datatracker.ietf.org/wg/jose/


難しいことも可能に

　OpenID Connectでは、クレームの扱いについて次のような機能を定義しています。

  • 外部クレームの提供（Aggregated Claims、Distributed Claims）
  • クレームの暗号化（Encrypted Claims）

　RPが、複数のOPが持つユーザーのクレームを取得したいとき、それぞれのOPに属性情報を要求するのは手間がかかります。OpenID Connectではこのような外部クレームをやりとりするために「集約クレーム」と「分散クレーム」の2つを規定しています。

　集約クレームとは、別のOPが持つクレームを署名付きで提供することです。RPからリクエストを受けたOPは、事前に取得していた、もしくは動的に取得した別のOPのクレームをレスポンスに含みます。

　一方、分散クレームではクレームそのものではなく、問い合わせ先のURLを扱います。PublicなクレームであればエンドポイントのURL、ユーザー認可が必要な場合はエンドポイントのURLとOAuth 2.0のアクセストークンをレスポンスに含みます。

　以下に外部クレームを含むデータ表現の例を示します。

{
    "name": "Ryo Ito",
    "given_name": "Ryo",
    "family_name": "Ito",
     ...
    "_claim_names": {
        "address": "src1",
        "credit_score": "src2"
    },
    "_claim_sources": {
        "src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"},
        "src2": {"endpoint": "https://creditagency.example.com/claimshere",
                 "access_token": "ksj3n283dke"}
    }
}

　“_claims_names”はクレーム名と取得元の識別子、“_claims_sources”は取得元の識別子と値を表しています。集約クレームである“address”は署名付きのJWT形式で表現され、分散クレームである“credit_score”はエンドポイントとアクセストークンにより表現されています。

　OPは、扱うクレームの内容によって、集約クレームと分散クレームのどちらを利用すべきかを判断する必要があります。頻繁に更新されるものは分散クレーム、一定期間変更されないことが保証されておりキャッシュの効果があるものは集約クレーム、という使い分けもできるかもしれません。

　また、よりセキュアなユースケースのために、クレームを暗号化してやりとりする方法も定義されています。OPはJSONデータで表現されたクレームをJSON Web Encryption（JWE）により暗号化してRPに渡します。RPは復号してクレームを取得することで、データをよりセキュアにやりとりできます。

　この機能により、NIST SP 800-63-1で定義されているすべてのユーザー認証要件（LoA）への対応が可能です。これは、OpenID Connectが金融システムや電子政府／行政システムにも利用できることを意味します。

モジュラーデザイン

　上記のようなさまざまなユースケースに対応するため、OpenID Connectは複数の仕様から成り立っており、それらをモジュール的に組み合わせることで多様な環境をサポートできます。

Copyright © ITmedia, Inc. All Rights Reserved.

　　　　　　 | 次のページへ
ページトップに戻る