ID連携の歴史とOpenID-Connect概要

Transcript

1. 1

2. 2 https://idmlab.eidentity.jp ⾃⼰紹介

3. 3 https://auth0.com/resources/ebooks/jp-the- openid-connect-handbook

4. Identity、アイデンティティ、ID

5. そもそもIDとは︖ • IDは何の略︖ • Identifier︓識別⼦ • 特定の集合の中で⼀意に識別するための属性情報（⼀つとは限らない） • ⽇本の中に「富⼠榮」は複数いるので苗字は識別⼦にならないが、⼤阪府の中なら苗字で 識別できる

   • Identity︓アイデンティティ • 実体（⼈など）を構成する属性の集合（ISO/IEC 24760-1より） • 識別⼦もアイデンティティを構成する要素の⼀つ 5 ⽇本 ⼤阪府 富⼠榮 富⼠榮 富⼠榮 富⼠榮 要素 解説 例 属性 後天的に取得された主体に関わる情報 （後から変化する） 名前、電話番号、社員番号、メールアド レス、認証状態、位置情報 好み 主体の嗜好に関わる情報 ⽢いものが好き 形質 主体の先天的な特有の性質 （後から変化しにくい） ⽣年⽉⽇、性別︖ 関係性 他の主体との関係に関わる情報（⼀部属性と重複） XX⼤学卒業、YY部所属 「ID管理」で⾔う IDはこちら

6. 出典）@_NAT ZONE https://www.sakimura.org/2011/06/1124/ Copyright 2020 OpenID Foundation Japan - All

   Rights Reserved. 6 Entity（実体）は直接観測できない Identityとは属性の集合である ⇒⾃分も他⼈もIdentity（属性）を通じて Entityを認識している ・姓が「富⼠榮」というEntity ・国籍が「⽇本」というEntity コンテキストとプライバシ • ⾃観︓提供する属性を通じ、 他⼈に⾒てほしい「⾃⼰像」 • 他観︓提供された属性を通じ、 実際に感じ取った「⾃⼰像」 ⇒混ざったり、ズレたりすると問題になる ⼈はIdentityを通じてEntity（実体）を認識する

7. エンタープライズIDのトレンド

8. 最近の重要キーワード • グループ＆グローバル • ⾃社内だけ、 • グループ企業内だけ、 • 国内だけ、 ではビジネスが完結しない、競争⼒が維持できない

   • ワークスタイル変⾰ • ダイバーシティ、働き⽅の多様化 8

9. IT基盤に与える影響 9 グループ ＆グローバル ワークスタイル 変⾰ ネットワーク デバイス アプリケーション M&Aによる頻繁な

   WAN構成の変更 ⾃宅、ホテルなど 社外からの利⽤ IT管理者のいない 拠点への対応 モバイル、BYOD 場所・デバイスに 囚われず共同利⽤ ⇒クラウド活⽤ ネットワークに依 存しないセキュリ ティ境界が必要 デバイス管理とデ バイスを問わない 柔軟なアクセス クラウドサービス との柔軟な連携 IT基盤として の考慮事項 キーワード

10. 社内・社外はFirewallで区 切られており、社内から のみ利⽤させる ⽀給PCのみから利⽤され る前提 社内アプリのみとの連携 （SSO,ID管理） 従来のID基盤 ID基盤の対応 10

    ネットワークに依 存しないセキュリ ティ境界が必要 デバイス管理とデ バイスを問わない 柔軟なアクセス クラウドサービス との柔軟な連携 今後のID基盤 インターネット経由の利 ⽤が前提 デバイス管理との⼀体化 クラウドサービスとのID 連携 （SSO,ID管理） グループ ＆グローバル ワークスタイル 変⾰ ネットワーク デバイス アプリケーション M&Aによる頻繁な WAN構成の変更 ⾃宅、ホテルなど 社外からの利⽤ IT管理者のいない 拠点への対応 モバイル、BYOD 場所・デバイスに 囚われず共同利⽤ ⇒クラウド活⽤ IT基盤として の考慮事項 キーワード

11. 従来のエンタープライズID基盤 11 管理者 源泉情報（⼈事DB等） ID管理システム 統合認証システム アプリケーション - IDライフサイクル管理機能 （⼈事業務/イベントに合わせた

    アカウント管理） - ID同期機能 （認証⽤IDの同期） SSO 利⽤者 IDメンテナンス - PWDリセット - ID作成/更新/削除 IDメンテナンス - PWDリセット、 - プロファイル メンテナンス 認証機能（統合認証システム） • ID/PWDなどでログオン制御を⾏う • アプリケーションの認証機能を外出し、共同で利⽤することでシングルサインオ ンを実現する • ⼀般に、認証に使うID情報（社員番号やパスワード）はID管理システムを使っ て管理される 認可機能（アプリケーション） • ログオン後、ユーザの権限（メニューを出す・出さない等）制御を⾏う • ⼀般に制御⾃体はアプリケーション側で⾏い、認可に必要な情報（役職や所属組 織）はID管理システムを使って管理される ID同期機能（ID管理システム） • ID管理システムから認証システムへ、認証に使うID情報（社員番号やパスワー ド）を同期する • ID管理システムからアプリケーションへ、認可に使うID情報（役職や所属組 織）を同期する - ID同期機能 （認可⽤IDの同期） IDライフサイクル管理機能（ID管理システム） • ID情報を源泉（⼈事等）から取り込み、⼈事イベントに応じて認証システムや 各アプリケーションへ必要なID情報を同期する • 管理者や利⽤者⾃⾝でIDのメンテナンスを⾏う（パスワード・リセット、プロ ファイルメンテナンス等） ID（アイデンティティ）基盤 個別アプリケーションの運⽤に 合わせたID配信ロジックの作り こみ アプリケーションと密結合した 認証システム

12. クラウド利⽤・グローバル化による変化 12 管理者 源泉情報（⼈事DB等） ID管理システム 統合認証システム アプリケーション SSO 利⽤者 親会社

    管理者 ID管理システム アプリケーション SSO 利⽤者 源泉情報（⼈事DB等） 統合認証システム 関係会社 業務要件 アプリケーションの共同利⽤ 利⽤要件 SSO継続 管理・運⽤要件 共同利⽤アプリケーションへ の複数社からのID同期

13. IDaaS（Identity as a Service）の活⽤へ 13 管理者 個社 源泉情報 （⼈事DB等） 個社

    ID管理システム 個社 統合認証 システム 個社アプリ SSO 利⽤者 管理者 個社 ID管理システム 個社アプリ 利⽤者 個社 源泉情報 （⼈事DB等） 個社 統合認証 システム 親会社 関係会社 SaaSアプリ （共同利⽤） SSO IDaaS （共同利⽤） ID連携 （対APL） ID連携 （対認証SYS） ID同期 （対APL） ID同期 （対ID管理） IDaaSに求められる要件 個社のシステムや運⽤を極⼒変えずに、共同利 ⽤アプリケーションを各社が便利かつセキュア に利⽤できるようにすること ⇒クラウド提供されるコントロールポイント

14. ID連携、フェデレーション、SSO

15. 認証/シングルサインオン）原始的なSSO • シングルサインオン • アプリケーション毎に持っていた認証機能を外部へ出し⼀元化 • 認証Cookieを共有することでシングルサインオンを実現 15 分散管理状態（SSO不可） アプリケーション

    アプリケーション 認証サーバ アプリケーション アプリケーション 認証サーバの外部化、 認証Cookieを共有（SSO可） Cookie有効範囲 （ドメイン） ドメイン外アプリ Cookieが共有不可 ⇒SSO不可

16. 認証/シングルサインオン）WAMの活⽤ • WAM（Web Access Management）による解決 • アプリケーション側にAgentを導⼊し認証状態を確認、Cookieの有効範囲 （ドメイン）を超えたSSOを実現 16 認証サーバ

    アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外アプリ Agent 認証状態の確認 ドメイン外はAgentが認証状態を問い合わせてSSO Agent Agent導⼊が不可、 認証サーバと通信 不可なアプリ ⇒SSO不可

17. 認証/シングルサインオン）ID連携/フェデレーション • ID連携/フェデレーションによる解決 • 認証結果表明（アサーション）をクライアント（ブラウザ）を経由して受け渡 すことにより、Cookieの有効範囲（ドメイン）を超えたSSOを実現 • アプリケーションと認証サーバ間の直接の通信が不要なので、クラウドに最適 17 認証サーバ

    アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ アサーション ドメイン外はアサーションを渡すことでSSO 連携⽅法や形式の 標準化が重要 ⇒SAML,OpenID Connect

18. 認証/シングルサインオン）構成の⽐較 構成パターン ドメイン跨ぎ のSSO アプリケーション構成 アプリ ⇒認証サーバ通信 適⽤対象の例 認証Cookieの 共有

    不可 同⼀認証Cookieを利⽤ する必要あり 不要 ⼩規模イントラネット、 ⾃前アプリのみ WAM 可 Agent導⼊が必要 必要 ⼤規模イントラネット、 Agent導⼊可能アプリ のみ ID連携 可 ID連携プロトコルへの 対応が必要 不要 ⼤規模分散環境（イン トラ/B2B/クラウド） 18 最近のニーズにはID連携 パターンがマッチ

19. 主なID連携プロトコル プロトコル 主な利⽤シーン 特徴 ws-federation 今となってはほぼMicrosoftワール ドのみ︖ Azure AD、AD FS

    SAMLトークン（XML形式）など HTTP/SOAPベース ws-*に依存 SAML2.0 エンタープライズの主流 G Suite、Salesforce、BOX等 SAMLトークン（XML形式） HTTP/SOAPベース OpenID Connect （OIDC） コンシューマからエンタープライズ へ拡⼤ Azure AD、LINE、Yahoo! JAPAN Office365はws-fed+OIDCのハイ ブリッド） OAuth2.0ベース トークン形式はJWT（JSON Web Token） HTTPベース 軽量、実装が簡単 19

20. OpenID Connect

21. OpenID Connectとは • OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルな

    アイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイ デンティティを検証可能にする. また同時に End-User の必要最低限の プロフィール情報を, 相互運⽤可能かつ RESTful な形で取得することも 可能にする. • OpenID Connect Core 1.0 ⽇本語訳 • http://openid-foundation-japan.github.io/openid-connect-core- 1_0.ja.html • OpenIDファウンデーション・ジャパン翻訳・教育WG Copyright Naohiro Fujie, 2019 21

22. OpenID Connect︓認証とID連携 • 認証のための技術ではない • ID連携のための技術 • Identity情報を • Identity

    Providerから • Relying Partyへ • 安全に伝達する仕組み • 安全に︖ • デジタル署名 • 暗号化 • 宛先の限定 22 NIST SP800-63 Digital Identity Modelより

23. OAuth2.0とは • OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービス への限定的なアクセスを可能にする認可フレームワークである. • RFC 6749:

    The OAuth 2.0 Authorization Framework ⽇本 語訳 • http://openid-foundation-japan.github.io/rfc6749.ja.html • OpenIDファウンデーション・ジャパン翻訳・教育WG Copyright Naohiro Fujie, 2019 23

24. • サードパーティアプリケーション︓OAuthクライアント • HTTPサービス︓リソースサーバ • 限定的なアクセス︓スコープ • 可能にする（サービス）︓認可サーバ Copyright Naohiro

    Fujie, 2019 24 OAuthクライアント （Webアプリ、スマホアプリなど） リソースサーバ （API、サービス） 認可サーバ （OAuthサーバ） 利用者 （リソースオーナー） スコープに基づき許可 （認可） 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有

25. 典型的な使われ⽅ • カレンダーアプリとGoogle Calendarの連携 Copyright Naohiro Fujie, 2019 25 カレンダーアプリ

    Google Calendar API Google Account 利用者 （リソースオーナー） カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有

26. 認証/ID連携（OAuth認証）の誤⽤理由① • アクセス許可を⾏う前にログインする為、アクセストークンを認証の結果得 られたものとして扱ってしまう Copyright Naohiro Fujie, 2019 26 カレンダーアプリ

    Google Calendar API Google Account 利用者 （リソースオーナー） カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有 ログイン（認証）

27. 認証/ID連携（OAuth認証）の誤⽤理由② • 殆どのサービスがプロファイル取得APIを⽤意しており、アクセストークンで ID情報の取得が可能。アクセストークンの持ち主＝リソースオーナーと みなしてしまう Copyright Naohiro Fujie, 2019 27

    カレンダーアプリ Google Account API Google Account 利用者 （リソースオーナー） カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有 ID情報の取得が可能

28. よく考えると • アクセストークンは無記名式の切符（誰が持ってきてもOK） • 認可サーバはアクセストークンの有効性検証は出来るが、持参⼈＝発⾏者かどうか は検証できない • 何故なら、 • 基本的にアクセストークンは単なる⽂字列（ハンドルトークン）

    • ※最近はJWT形式のAssertion Tokenもありますがややこしくなるので割愛 • 認可サーバには以下のように保存されている（イメージ） • Authorization HeaderにBearer xxxx（トークン）って書きますよね︖ • Bearer（ベアラ）＝持参⼈。持ってきた⼈に利⽤を許可する、ということ • 参考）https://idmlab.eidentity.jp/2013/09/bearer-token.html Copyright Naohiro Fujie, 2019 28 アクセストークン 発⾏者 有効期限 スコープ nQ6wtY3K#UCWRtE6 Yamada Taro 2019-03-15 18:30:00 Email Profie xU,RRjaa.iZLnNgJ Tanaka Hanako 2019-03-15 19:00:00 Calendar.Read

29. OAuth2.0とは • OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービス への限定的なアクセスを可能にする認可フレームワークである. • RFC 6749:

    The OAuth 2.0 Authorization Framework ⽇本 語訳 • http://openid-foundation-japan.github.io/rfc6749.ja.html • OpenIDファウンデーション・ジャパン翻訳・教育WG Copyright Naohiro Fujie, 2019 29 認証/ID連携は仕様のスコープ外

30. 認証/ID連携に使うには︖ • OAuthクライアントがリソースサーバ側のユーザ情報を取得できること • 認証された結果を把握できること • リソースオーナーのID情報を把握できること • OpenID Connectにおける実現⽅法＝アイデンティティレイヤー

    • ID Token ︓ 認証結果（アサーション）の取得⽅法の標準化 • UserInfoエンドポイント ︓ ID情報の取得⽅法の標準化 ※ID TokenにもID情報を含められるがトークンのサイズの巨⼤化の問題や認証時以外の情報取得に対応するため UserInfoを使⽤ Copyright Naohiro Fujie, 2019 30

31. OpenID Connectとは • OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルな

    アイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイ デンティティを検証可能にする. また同時に End-User の必要最低限の プロフィール情報を, 相互運⽤可能かつ RESTful な形で取得することも 可能にする. • OpenID Connect Core 1.0 ⽇本語訳 • http://openid-foundation-japan.github.io/openid-connect-core- 1_0.ja.html • OpenIDファウンデーション・ジャパン翻訳・教育WG Copyright Naohiro Fujie, 2019 31 アイデンティティレイヤー ＝ ID Token、UserInfoエンドポイント

32. OAuthとOpenID Connectの違いの例 （code flow） 項⽬ OAuth OpenID Connect 認可リクエストの パラメータ

    scope 任意 必須（openid） redirect_uri 任意 必須 nonce - 任意 セキュリティ対策 （code置き換えへの対策） PKCE （codeとセッション紐づけ） nonce （codeとid_tokenの紐づけ） トークンの種類 access_token （発⾏対象者の情報なし） id_token （発⾏対象者の情報あり） プロファイル取得⽅法 標準化対象外 userInfoエンドポイント Copyright Naohiro Fujie, 2019 32 キモは「scope=openid」と「id_token」と「userInfoエンドポイント」

33. 具体的なフロー （code flow） LINEの場合のエンドポイント • Authorization Endpoint • https://access.line.me/oauth2/v2.1/authorize •

    Token Endpoint • https://api.line.me/oauth2/v2.1/token • Profile Endpoint • https://api.line.me/v2/profile Copyright Naohiro Fujie, 2019 33

34. id_token • JWT（JSON Web Token）形式 • JSON Web Token (JWT)

    - draft-ietf-oauth-json-web-token-11 ⽇ 本語訳 • http://openid-foundation-japan.github.io/draft-ietf-oauth-json-web- token-11.ja.html • OpenIDファウンデーション・ジャパン翻訳・教育WG • 内部構造 • ヘッダ︓署名や暗号化形式など • ペイロード︓クレーム（属性）セット、暗号化する場合も • シグニチャ︓デジタル署名 • Base64Urlエンコードし、”.”で各パートを連結する • eyJhb̶snip--iJ9.eyJpc3̶snip--pwIn0.gC4ub--snip--yBm0 Copyright Naohiro Fujie, 2019 34

35. id_tokenの中⾝ • jwt.io（by Auth0）とかjwt.ms（by MS） Copyright Naohiro Fujie, 2019 35

36. id_tokenの中⾝（LINE Loginの例） Claim Type Value Notes iss https://access.line.me JWTの発行者（issuer）を表す識別子 sub

    U9f1cac4f164ef3f5c02c92d0067a 11a1 JWTの主体（subject）を表す識別子 LINEの場合はuserId aud 1516319320 JWTの発行先（audience）を表す識別子 LINEの場合はclient_id exp 1552324580 JWTの有効期限（UNIX Time） iat 1552320980 JWTの発行時刻（UNIX Time） nonce 51501f6a-9a12-4d42-ad72- 0d36e44df96f リクエスト時に設定したnonceの値 リクエストと発行されたid_tokenの中の値がマッチする かどうかを検査し置き換え攻撃を検知する name Naohiro Fujie 名前。LINEの場合は表示名 picture https://profile.line- scdn.net/0m0--snip-- xxx プロファイル写真のURL email naohiro.fujie@eidentity.jp メールアドレス Copyright Naohiro Fujie, 2019 36

37. まとめ

38. まとめ • Identity = 属性の集合。識別⼦（Identifier）は属性の⼀部 • グローバル化、働き⽅改⾰等によるクラウド・サービス利⽤促進により IDaaS（Identity as a

    Service）の利⽤は必然 • クラウドを前提としたSSO技術としてID連携が必要、標準化が推進 • OpenID Connectがコンシューマのみならずエンタープライズにおいても 利活⽤されている • OpenID ConnectはOAuthをベースにアイデンティティレイヤーを付加 したものである 38