Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up
for free
ID連携の歴史とOpenID-Connect概要
Auth0 Japan
March 19, 2020
Technology
1
370
ID連携の歴史とOpenID-Connect概要
2020年3月19日に行われたWebinarで使用した資料です。
Auth0 Japan
March 19, 2020
Tweet
Share
More Decks by Auth0 Japan
See All by Auth0 Japan
auth0japan
0
180
auth0japan
1
82
auth0japan
0
290
auth0japan
0
260
auth0japan
0
310
auth0japan
0
66
auth0japan
0
70
auth0japan
0
51
auth0japan
0
46
Other Decks in Technology
See All in Technology
ymas0315
0
180
clustervr
0
210
hmatsu47
0
210
shimacos
2
360
shomaekawa
3
1.3k
hololab
0
360
chaspy
1
470
qryuu
7
5k
con_mame
4
2k
nwiizo
1
370
kraj
0
5.2k
yosshi_
2
710
Featured
See All Featured
lauravandoore
11
1.3k
denniskardys
220
120k
productmarketing
5
660
tammielis
237
23k
jacobian
255
20k
brettharned
93
3k
mthomps
39
2.3k
morganepeng
92
14k
hatefulcrawdad
257
17k
jnunemaker
PRO
40
4.6k
paulrobertlloyd
71
1.4k
colly
65
3k
Transcript
1
2 https://idmlab.eidentity.jp ⾃⼰紹介
3 https://auth0.com/resources/ebooks/jp-the- openid-connect-handbook
Identity、アイデンティティ、ID
そもそもIDとは︖ • IDは何の略︖ • Identifier︓識別⼦ • 特定の集合の中で⼀意に識別するための属性情報(⼀つとは限らない) • ⽇本の中に「富⼠榮」は複数いるので苗字は識別⼦にならないが、⼤阪府の中なら苗字で 識別できる
• Identity︓アイデンティティ • 実体(⼈など)を構成する属性の集合(ISO/IEC 24760-1より) • 識別⼦もアイデンティティを構成する要素の⼀つ 5 ⽇本 ⼤阪府 富⼠榮 富⼠榮 富⼠榮 富⼠榮 要素 解説 例 属性 後天的に取得された主体に関わる情報 (後から変化する) 名前、電話番号、社員番号、メールアド レス、認証状態、位置情報 好み 主体の嗜好に関わる情報 ⽢いものが好き 形質 主体の先天的な特有の性質 (後から変化しにくい) ⽣年⽉⽇、性別︖ 関係性 他の主体との関係に関わる情報(⼀部属性と重複) XX⼤学卒業、YY部所属 「ID管理」で⾔う IDはこちら
出典)@_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(実体)を認識する
エンタープライズIDのトレンド
最近の重要キーワード • グループ&グローバル • ⾃社内だけ、 • グループ企業内だけ、 • 国内だけ、 ではビジネスが完結しない、競争⼒が維持できない
• ワークスタイル変⾰ • ダイバーシティ、働き⽅の多様化 8
IT基盤に与える影響 9 グループ &グローバル ワークスタイル 変⾰ ネットワーク デバイス アプリケーション M&Aによる頻繁な
WAN構成の変更 ⾃宅、ホテルなど 社外からの利⽤ IT管理者のいない 拠点への対応 モバイル、BYOD 場所・デバイスに 囚われず共同利⽤ ⇒クラウド活⽤ ネットワークに依 存しないセキュリ ティ境界が必要 デバイス管理とデ バイスを問わない 柔軟なアクセス クラウドサービス との柔軟な連携 IT基盤として の考慮事項 キーワード
社内・社外はFirewallで区 切られており、社内から のみ利⽤させる ⽀給PCのみから利⽤され る前提 社内アプリのみとの連携 (SSO,ID管理) 従来のID基盤 ID基盤の対応 10
ネットワークに依 存しないセキュリ ティ境界が必要 デバイス管理とデ バイスを問わない 柔軟なアクセス クラウドサービス との柔軟な連携 今後のID基盤 インターネット経由の利 ⽤が前提 デバイス管理との⼀体化 クラウドサービスとのID 連携 (SSO,ID管理) グループ &グローバル ワークスタイル 変⾰ ネットワーク デバイス アプリケーション M&Aによる頻繁な WAN構成の変更 ⾃宅、ホテルなど 社外からの利⽤ IT管理者のいない 拠点への対応 モバイル、BYOD 場所・デバイスに 囚われず共同利⽤ ⇒クラウド活⽤ IT基盤として の考慮事項 キーワード
従来のエンタープライズ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 管理者 源泉情報(⼈事DB等) ID管理システム 統合認証システム アプリケーション SSO 利⽤者 親会社
管理者 ID管理システム アプリケーション SSO 利⽤者 源泉情報(⼈事DB等) 統合認証システム 関係会社 業務要件 アプリケーションの共同利⽤ 利⽤要件 SSO継続 管理・運⽤要件 共同利⽤アプリケーションへ の複数社からのID同期
IDaaS(Identity as a Service)の活⽤へ 13 管理者 個社 源泉情報 (⼈事DB等) 個社
ID管理システム 個社 統合認証 システム 個社アプリ SSO 利⽤者 管理者 個社 ID管理システム 個社アプリ 利⽤者 個社 源泉情報 (⼈事DB等) 個社 統合認証 システム 親会社 関係会社 SaaSアプリ (共同利⽤) SSO IDaaS (共同利⽤) ID連携 (対APL) ID連携 (対認証SYS) ID同期 (対APL) ID同期 (対ID管理) IDaaSに求められる要件 個社のシステムや運⽤を極⼒変えずに、共同利 ⽤アプリケーションを各社が便利かつセキュア に利⽤できるようにすること ⇒クラウド提供されるコントロールポイント
ID連携、フェデレーション、SSO
認証/シングルサインオン)原始的なSSO • シングルサインオン • アプリケーション毎に持っていた認証機能を外部へ出し⼀元化 • 認証Cookieを共有することでシングルサインオンを実現 15 分散管理状態(SSO不可) アプリケーション
アプリケーション 認証サーバ アプリケーション アプリケーション 認証サーバの外部化、 認証Cookieを共有(SSO可) Cookie有効範囲 (ドメイン) ドメイン外アプリ Cookieが共有不可 ⇒SSO不可
認証/シングルサインオン)WAMの活⽤ • WAM(Web Access Management)による解決 • アプリケーション側にAgentを導⼊し認証状態を確認、Cookieの有効範囲 (ドメイン)を超えたSSOを実現 16 認証サーバ
アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 (ドメイン) ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 (ドメイン) ドメイン外アプリ Agent 認証状態の確認 ドメイン外はAgentが認証状態を問い合わせてSSO Agent Agent導⼊が不可、 認証サーバと通信 不可なアプリ ⇒SSO不可
認証/シングルサインオン)ID連携/フェデレーション • ID連携/フェデレーションによる解決 • 認証結果表明(アサーション)をクライアント(ブラウザ)を経由して受け渡 すことにより、Cookieの有効範囲(ドメイン)を超えたSSOを実現 • アプリケーションと認証サーバ間の直接の通信が不要なので、クラウドに最適 17 認証サーバ
アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 (ドメイン) ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 (ドメイン) ドメイン外 アプリ アサーション ドメイン外はアサーションを渡すことでSSO 連携⽅法や形式の 標準化が重要 ⇒SAML,OpenID Connect
認証/シングルサインオン)構成の⽐較 構成パターン ドメイン跨ぎ のSSO アプリケーション構成 アプリ ⇒認証サーバ通信 適⽤対象の例 認証Cookieの 共有
不可 同⼀認証Cookieを利⽤ する必要あり 不要 ⼩規模イントラネット、 ⾃前アプリのみ WAM 可 Agent導⼊が必要 必要 ⼤規模イントラネット、 Agent導⼊可能アプリ のみ ID連携 可 ID連携プロトコルへの 対応が必要 不要 ⼤規模分散環境(イン トラ/B2B/クラウド) 18 最近のニーズにはID連携 パターンがマッチ
主な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
OpenID Connect
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
OpenID Connect︓認証とID連携 • 認証のための技術ではない • ID連携のための技術 • Identity情報を • Identity
Providerから • Relying Partyへ • 安全に伝達する仕組み • 安全に︖ • デジタル署名 • 暗号化 • 宛先の限定 22 NIST SP800-63 Digital Identity Modelより
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
• サードパーティアプリケーション︓OAuthクライアント • HTTPサービス︓リソースサーバ • 限定的なアクセス︓スコープ • 可能にする(サービス)︓認可サーバ Copyright Naohiro
Fujie, 2019 24 OAuthクライアント (Webアプリ、スマホアプリなど) リソースサーバ (API、サービス) 認可サーバ (OAuthサーバ) 利用者 (リソースオーナー) スコープに基づき許可 (認可) 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有
典型的な使われ⽅ • カレンダーアプリとGoogle Calendarの連携 Copyright Naohiro Fujie, 2019 25 カレンダーアプリ
Google Calendar API Google Account 利用者 (リソースオーナー) カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有
認証/ID連携(OAuth認証)の誤⽤理由① • アクセス許可を⾏う前にログインする為、アクセストークンを認証の結果得 られたものとして扱ってしまう Copyright Naohiro Fujie, 2019 26 カレンダーアプリ
Google Calendar API Google Account 利用者 (リソースオーナー) カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有 ログイン(認証)
認証/ID連携(OAuth認証)の誤⽤理由② • 殆どのサービスがプロファイル取得APIを⽤意しており、アクセストークンで ID情報の取得が可能。アクセストークンの持ち主=リソースオーナーと みなしてしまう Copyright Naohiro Fujie, 2019 27
カレンダーアプリ Google Account API Google Account 利用者 (リソースオーナー) カレンダーアプリに対してア イテムの読み出しを許可 認可に基づき アクセストークンを発行 アクセストークンを 提示してアクセス リソースを所有 ID情報の取得が可能
よく考えると • アクセストークンは無記名式の切符(誰が持ってきても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
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連携は仕様のスコープ外
認証/ID連携に使うには︖ • OAuthクライアントがリソースサーバ側のユーザ情報を取得できること • 認証された結果を把握できること • リソースオーナーのID情報を把握できること • OpenID Connectにおける実現⽅法=アイデンティティレイヤー
• ID Token ︓ 認証結果(アサーション)の取得⽅法の標準化 • UserInfoエンドポイント ︓ ID情報の取得⽅法の標準化 ※ID TokenにもID情報を含められるがトークンのサイズの巨⼤化の問題や認証時以外の情報取得に対応するため UserInfoを使⽤ Copyright Naohiro Fujie, 2019 30
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エンドポイント
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エンドポイント」
具体的なフロー (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
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
id_tokenの中⾝ • jwt.io(by Auth0)とかjwt.ms(by MS) Copyright Naohiro Fujie, 2019 35
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
まとめ
まとめ • Identity = 属性の集合。識別⼦(Identifier)は属性の⼀部 • グローバル化、働き⽅改⾰等によるクラウド・サービス利⽤促進により IDaaS(Identity as a
Service)の利⽤は必然 • クラウドを前提としたSSO技術としてID連携が必要、標準化が推進 • OpenID Connectがコンシューマのみならずエンタープライズにおいても 利活⽤されている • OpenID ConnectはOAuthをベースにアイデンティティレイヤーを付加 したものである 38