パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

工藤達雄
OpenIDファウンデーション・ジャパン
パスワード氾濫時代のID管理とは？
～最新のOpenIDが目指すユーザー認証の効率的な強化～

Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
アジェンダ
不正アクセス対策としての「ID連携」
ID連携技術概要（SAML、OpenID、OAuth）
最新のID連携仕様 “OpenID Connect”

自己紹介
 工藤達雄 http://www.linkedin.com/in/tatsuokudo, @tkudos
 サン・マイクロシステムズ (1998~2008)
https://blogs.oracle.com/tkudo
 野村総合研究所 (2008~)
 OpenIDファウンデーション・ジャパン
(2013~)
http://openid.or.jp/blog

不正アクセス対策としての
「ID連携」

パスワード管理は限界にきている
3種類以下のパスワードを使いまわすユーザが約7割 /
2人に1人はパスワードを変更する習慣なし
Source: トレンドマイクロ、2012年12月14日発表
自分のIDでログインして利用するサイ
トの数は平均19.40 / 記憶できるIDと
パスワードの組み合わせは平均3.15
Source: 野村総合研究所、2012年2月8日発表

急増するパスワードリスト攻撃
 自分の運営するサイトでは
適切にID管理をしていても
ユーザーがID/パスワードを
使いまわしているために
弱いサイトから漏れて
しまう
Source:情報処理推進機構

ユーザー側に負担
 対策として「サイトごとにパスワードを
変える」
 本当に可能だろうか?
 パスワードマネージャーの導入
 サイトごとのパスワードを自動生成し、
ログインを支援するツール
 ブラウザの標準機能としてサポートする
ケースも出てきたが…
→ いずれもユーザー側に対応を求めている
「個人の利用者がパスワードリスト
攻撃による最終的な被害者に
ならないようにするためには、
すべてのインターネットサービスで
異なるパスワードを設定する必要が
あります」
Source: 情報処理推進機構

事業者側の対策の動向
 2要素認証
 大手サイトが相次いで導入している
 しかし2要素認証を行なうサイトが多数乱立するようになると
ユーザーにとっては不便
 リスクベース認証
 不正アクセスかどうかを判定し、必要に応じて高度認証を実施
→ サービス側の導入・運用が容易ではない

「Webアプリケーションのユーザー認証・認可」を
シーケンスとして考えてみる
1
2
3
7
4
5
8
9
2. 「ログインして
ください」
3. ID/パスワード
を入力
1. アクセス
試行 4. ID/パスワード
を照合
アプリケー
ション
ID情報
DB
ユーザー
5. 照合OK
（属性を返却）
7. ユーザーに応じた
サービスを提供 8. アクセス試行
（ログイン済み）
9. ユーザーに応じた
サービスを提供
6
6. アクセス
認可決定

サービスが個別にユーザー認証・認可を行なう
2
3
7
4
5
を入力
アプリ
ケーションA
ID情報
DB
ユーザー 6
1
9
10
14
11
12
を入力
ID情報
DB
13
8 アプリ
ケーションB
ください」
ください」

事業者による個別対応は、ユーザーの利便性をさらに
下げることに
2
3
7
4
5
3. ID/パスワード、
OTP、…
アプリ
ケーションA
ID情報
DB
ユーザー
6
1
9
10
14
11
12
10. ID/パスワード、厳しい
パスワードポリシー、…
ID情報
DB
13
8 アプリ
ケーションB
ユーザー認証
プロセス、
パスワードポリシー、
認証に必要な
デバイスの
管理などが、
サイトごとに
バラバラ

アイデンティティ&アクセス管理（IAM）システムを
導入し、ユーザー認証・認可を一元化する
2
3
7
4
5
アプリ
ケーションA
ID情報
DB
ユーザー
6
1
9
3. ID/パスワードを
入力
8 アプリ
ケーションB
2. 「ログインしてください」
を照合
5. 照合OK
（属性を返却）
6. アクセス
認可決定
IAMシステム
1. アクセス試行
7. ユーザーに応じたサービスを提供
8. アクセス試行
9. ユーザーに応じたサービスを提供

IAMの利点と限界
 効率的にセキュリティの向上を図ることができる
 タイムリーなアカウント改廃、サービス全体を統一するユーザー認
証・認可、パスワードポリシー、不正アクセス検知機能などの統合
 ユーザーにとっての利便性が高まる
 シングル・サインオン、プロファイル情報の共通化
 しかし、基本的には同一企業グループ内でしか使えない
 グループ企業であっても、ビジネス的に統合できないケースも

「一元化」のアプローチは魅力的だが、事業ドメイン
が異なるサービスに対しては容易に適用できない
アプリ
ケーションA
アプリ
ケーションB
ID情報
DB
ユーザー
A社
B社
ビジネス関係や法規制等
の制限から、ID情報を
共通化することは難しい
ID情報
DB

ID（アイデンティティ）連携:
ユーザーの同意にもとづくID情報の要求・提供
アプリ
ケーションA
アプリ
ケーションB
ID情報
DB
ユーザー
A社
B社
ID情報
DB
1
2
4
5
6
11
3
8
7
9
10
14
12
13
15
ください」
を入力
1. アクセス
試行
2. 認証
リクエスト
11. 認証
レスポンス
（ID情報）
5. ID/
パスワードを
照合
6. 照合
OK
9. 属性
取得
10. 属性
提供
7. 「ID情報
提供OK?」
8. ユーザー
による同意
15. ユーザーに
応じた
サービスを提供
12. 認証レスポンスに基づきユーザー
を特定し属性情報を要求
13. 属性
取得
14. アクセス
認可決定

ID（アイデンティティ）連携のポイント
 ID情報（認証結果、属性情報）が連携される
 パスワードのような秘密情報は流れない
 ユーザーの同意に基づいて行われる
 サービス同士が勝手にやりとりするのではない
 各サービスの独立性が保たれる
 外部から取得したID情報を用いてどのようにアクセスを認可するかは各サービスの判断に
委ねられる
→ システム的にもビジネス的にも有利

ID連携技術概要
（SAML、OpenID、OAuth）

ID（アイデンティティ）連携を実現する技術仕様
 技術仕様では、ID情報をどうやって要求・提供
するか（プロトコル）、それはどういう表現か
（メッセージ形式）を規定
 プロトコル: フロントチャネル（Webブラウザ等での
リダイレクトによる間接通信）、バックチャネル
（サーバー間の直接通信）、…
 メッセージの形式: XML、JSON、URLパラメー
ター、…
 普及しているオープン仕様は主に4種類
 SAML（サムル）
 OpenID（オープンアイディー）
 OAuth（オーオース）
 OpenID Connect（オープンアイディー・コネクト）
1
2 4
3
5
2. 認証
リクエスト
4. 認証
レスポンス
（ID情報 or
「引換証」）
ID情報
提供側
ID情報
要求側
ユーザー
1. アクセス
試行
5. サービス
提供
3. 認証・同意
4’
4’. 「引換
証」を送信
4’’
4’’. 認証
レスポンス
（ID情報）

Source: http://www.cafepress.com/oasis_open.20273829

SAML
(サムル; Security Assertion Markup Language)
 アイデンティティ情報を安全に
流通させるためのXML形式
および通信仕様
 ID連携を実現する主要要素を
4つに分解
 「アサーション」「プロトコル」
「バインディング」「プロファイル」
Profile
特定のユースケース（SSOなど）を実現するうえでの、
アサーション、プロトコル、バインディングの
組み合わせを規定。
Binding
リクエストおよびレスポンスの手続きを、実際にIdP
とRPの間でどのように実施するか規定。直接通信
（SOAP）や、ユーザエージェントを介在させる
HTTPリダイレクト通信などが存在。
Protocol
アサーションの送受信を実施するための
リクエストおよびレスポンスの手続き。
Assertion
ユーザのID名や認証方法およびそのユーザの
属性や権限に関する表明。

SAML 2.0 Web Browser SSO Profile
Webアプリケーション間のSSO向けのプロファイル
1
2 4
3
5
2. 認証
リクエスト
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:
assertion"
Version="2.0" IssueInstant="2005-01-31T12:00:00Z">
<saml:Issuer>www.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">j.doe@example.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore="2005-01-31T12:00:00Z"
NotOnOrAfter="2005-01-31T12:30:00Z"></saml:Conditions>
<saml:AuthnStatement AuthnInstant="2005-01-31T12:00:00Z"
SessionIndex="0">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:
PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
ID情報
提供側
(Identity
Provider)
ID情報
要求側
(Service
Provider)
ユーザー
1. アクセス
試行
5. サービス
提供
3. 認証・
同意
4’
4’. 「アーティ
ファクト」を送信
4’’
4’’. 「アサー
ション」
4. 認証レスポンス
（「アサーショ
ン」 or 「アーティ
ファクト」）
アサーションの例

SAMLの普及動向
 Google AppsやSalesforce.comなどのSaaS提供事業者が、利用企業との間の
ID連携のベースとして採用
 SaaS契約企業の社員が、社内SSO（シングル・サインオン）でユーザー認証を受け、
社外のSaaSにログイン
 その他、B2B（業務目的での企業間連携）や、高等教育機関でのフェデレーション・
ネットワークのベースとして採用
 cf. Global Trust Framework Survey - DG - Business Cases for Trusted Federations - Kantara Initiative
http://kantarainitiative.org/confluence/display/bctf/Global+Trust+Framework+Survey
 ただし、フェデレーション要件に応じてSAML仕様をどう使うか取り決める
（プロファイリング）必要があるため、フェデレーション・ネットワーク間の
相互運用性は低い

Source: http://openid.net/images/logo/openid-icon-1000x1000.png

SAMLの代替としてのOpenIDの登場
 「Webサイト間のID連携」に特化し、Webサイト開発者
にとって使いやすい仕様にした
 SAMLは包括的なフレームワークであるがゆえに複雑
 「ユーザーセントリック・アイデンティティ」（ユーザー
によるID連携のコントロール）を仕様に盛り込んだ
 SAMLは事業者中心のモデル

「OpenID 2.0」
 ふたつのWebサイト間における、Webブラウザを用いたID情報の要求・提供を
行うためのプロトコルとして、2007年12月に策定
 認証結果の要求・取得: OpenID Authentication 2.0
 属性情報の要求・取得: Attribute Exchange (AX) Extension 1.0
 認証ポリシーの公告・要求・表明: Provider Authentication Policy Extension (PAPE) 1.0
 ユーザー認証・同意ページのユーザー・インタフェースの指定: OpenID User Interface
Extension 1.0 （Draft)
 OpenID AuthenticationとOAuth 1.0のハイブリッド: OpenID OAuth Extension (Draft)

OpenID の概念と登場人物
 ユーザがアイデンティティ (ID) 情報の提供サイトを選択（実際にはホワイトリスト運用が一般的）
 OpenID プロバイダ (OP): ID 情報 (認証結果や属性情報) を RP に提供するサイト
 OpenID リライング・パーティ (RP): OP から提供された ID 情報を受け入れるサイト
RP (医療情報管
理サービス)
「本人以外には決し
て公開しない」
RP (無料日記
サービス)
「誰でも気軽にコメ
ントしてほしい」
RP(ホテル予約
サービス)
「確かな属性情報がほ
しい」
OP(ポータル
サイト)
誰でも即時アカ
ウント取得可能
OP(航空券
予約サービス)
クレジットカード
番号等を管理
OP(高度認証
サービス)
登録時に厳密な
本人確認を行ない、
多要素認証を実施
ID / パスワー
ドでログイン
ID情報の提供
ID / 画像認証
でログイン
ICカードの証
明書でログイ
ン
ID情報の提供
ID情報の提供
クレデンシャル情報（ID/PW等）の入力による
ユーザの特定はOP側で行うため、RP側にクレ
デンシャル情報を流通させる必要がない
OP：ID情報の提供側
RP：ID情報の受入側

OpenID Authentication 2.0
1
3 5
4
6
3. 認証
リクエスト
ID情報
提供側
(OpenID
Provider)
ID情報
要求側
(Relying
Party)
ユーザー
1. アクセス
試行
6. サービス
提供
4. 認証・
同意
2
2. 動的に
署名鍵を
共有
openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
openid.mode=id_res
openid.return_to=***
openid.claimed_id=https%3A%2F%2Fexample.jp%2F050af1f6-4547-4cc2-9e55-
78337e5c9156
openid.identity=https%3A%2F%2Fexample.jp%2Fa%2F050af1f6-4547-4cc2-9e55-
78337e5c9156
openid.assoc_handle=***
openid.realm=***
openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
openid.ax.mode=fetch_res%2Cax.value.genderponse
openid.response_nonce=***
openid.signed=assoc_handle%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint
%2Cresponse_nonce%2Creturn_to%2Csigned%2Cns.ax%2Cax.mode%2Cns.pape%2Cpape.au
th_policies%2Cpape.auth_level.ns.nist%2Cpape.auth_level.nist
openid.op_endpoint=https%3A%2F%2Fop.example.jp%2F
openid.ax.type.gender=http%3A%2F%2Faxschema.org%2Fperson%2Fgender
openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0
openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%
2F2007%2F06%2Fnone
openid.pape.auth_level.ns.nist=http%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fn
istpubs%2F800-63%2FSP800-63V1_0_2.pdf
openid.pape.auth_level.nist=0
openid.sig=***
5. アサーション（一部略）

OpenID 2.0の普及動向
 多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するた
めの API（Application Programming Interface）としてOpenIDを採用
 インターネットサービス事業者（例： Yahoo!、Google、ミクシィ）
 携帯通信事業者（例： NTTドコモ、KDDI、ソフトバンク）
 ネット決済事業者（例：楽天（楽天あんしん支払いサービス）、PayPal）
 公共性の高いサービスでのOpenIDの採用
 米国において、民間のIdP (Identity Provider：たとえばポータル事業者や決済事業
者など、市民に対してID を発行・運用する組織)と、連邦政府機関の市民向けWeb
サイトとのID連携プロトコルの一つとして採用

ユーザーの代理としてWeb APIにアクセスするクライアントの
アクセス認可をどのように実現するか
 「ユーザーのID/パスワード」を預かる
方法が広まってしまったが…
 ユーザーはサービスBのID/パスワードを
サービスAに漏らしている
▪ サービスAの情報漏えいや、サービスA自身に
よる不正利用の懸念が残る
 ユーザーはサービスAに全権委任する
かたちに
▪ サービスAは本来不要な（過剰な）API
アクセスを行うこともできてしまう
 使い勝手が悪い
▪ サービスBのID/パスワードを変更すると、
サービスAがアクセスできなくなる
▪ サービスAからサービスBへのアクセス可能
期間を指定できない
1
4
サービスB
（API提供側）
サービスA
（API利用側）
ユーザー
1. サービスBにある自身のコ
ンテンツを参照するために、
ユーザーがサービスBに
おけるID/パスワードを提供
4. サービスBの
コンテンツを
もとにサービス
を提供
2
2. サービスAが、
サービスBのID/
パスワードを用いて
代理ログインし、
APIにリクエストを
送信
3
3. サービスBの
ユーザーである
とみなし、処理
結果を返却

OpenIDをAPIのアクセス認可にも使えないか?
 2006年11月、TwitterのエンジニアやOpenIDコミュニティを
中心に、API代理認証にOpenIDを適用できないか議論が
始まった。結果的にOpenIDは適用できず、また当時API代理
認証のオープン標準と呼べるものはまだ存在しないことが
明らかになった。
 2007年4月、少人数にてプロトコル検討が始まり、7月には
仕様草案の初版をもとに公開の場にて議論されるように
なった。そして10月、OAuth 1.0の最終ドラフトが公開された。
Source: http://oauth.net/about/

OAuthの登場
 「トークン」による API アクセス
制御
 トークン: ユーザーに成り代わって
アクセスすることを示す符号
 「API プロバイダーがユーザーを
直接認証するフロー」が普及
 APIクライアントにID/パスワード
をもらさずに済む
 API 提供側はユーザー単位での
アクセス管理が可能
▪ トークンはユーザーとひもづいている
1
2 4
3
7
2. 認可
リクエスト
認可
サーバー/
リソース
サーバー
API
クライ
アント
ユーザー
1. アクセス
試行
7. サービス
提供
3. 認証・
同意
4’
4’. 「認可
コード」を
送信
4’’
4’’. 「アクセス
トークン」
4. 認可
レスポンス
（「認可コード」
or 「アクセス
トークン」）
5
5. API
アクセス
with アクセ
ストークン
6
6. APIレ
スポンス

OAuthの普及動向
 APIアクセス認可の事実上の標準フレームワークとして広く普及
 ソーシャル・ネットワーク: Facebook, Twitter, ミクシィ, Google+, GREE, Ameba, Windows Live, LinkedIn, …
 エンタープライズ: Google Apps, Microsoft Office 365, Salesforce.com, …
 EC/決済/ポイント: 楽天、Yahoo!、PayPal、カラーミーショップ、Amazon.com、サントリー、リクルート、…
 パーソナル・クラウド: Dropbox、Evernote、…
 銀行/証券: AXA Banque, E*TRADE, Capital One, …
 通信事業者: NTTドコモ
 テレマティクス: GM OnStar
 ゲーム: スクエアエニックス、虎の穴、エイチーム、EA、…
 スマートグリッド：会津若松スマートシティ推進協議会
 その他多数

OAuth仕様には「ID情報」の扱い方は書かれていない
 アクセストークンは「権限が移譲されたことを
示す情報」であり、認証結果や属性情報では
ない
 実運用ではアクセストークンに加えてID情報も
扱うよう独自拡張を行なうケースが多い
 認可リクエストに要求属性を指定
 「アクセストークンレスポンス」にID情報を示す
キー/値を追加
 アクセストークン自体を構造化し、ID情報を包含
 アクセストークンを受け取ってID情報を返却する
APIを提供 {
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
アクセストークン（レスポンス）の例
1
2 4
3
7
2. 認可
リクエスト
認可
サーバー/
リソース
サーバー
API
クライ
アント
ユーザー
1. アクセス
試行
7. サービス
提供
3. 認証・
同意
4’
4’. 「認可コード」
を送信
4’’
トークン」
4. 認可
レスポンス
or 「アクセス
トークン」）
5
5. API
アクセス
with アクセス
トークン
6
6. APIレスポンス

最新のID連携仕様
“OpenID Connect”

SAML、OpenID、OAuthではダメなのか!?
Pros Cons
SAML •仕様がモジュール化されており、
拡張性が高い
•署名や暗号化などを用いてセキュ
リティを強化できる
•仕様群が膨大
•XMLの検証や署名、暗号化などが複雑
であり、実装が容易ではない
•RESTful APIとはなじまない
OpenID •認証結果と属性情報の要求・提供
に機能を限定して標準化されてお
り、相互接続性が高い
•鍵共有、署名の付与・検証が面倒
•平文のID情報がWebブラウザ経由で流
れるため、内容が露見
•APIアクセス認可への応用は不可能
OAuth •他の仕様と比較してシンプル
•スコープによるアクセス権限指定、
Authorizationヘッダの利用など、
「RESTful API」との親和性が高い
•Webブラウザだけではなく、モバ
イルネイティブやJavaScriptなど、
モダンなクライアント環境を考慮
している
•認証結果と属性情報の要求・提供が定
義されておらず、事業者の独自拡張が
乱立
1
2 4
3
5
2. 認証
リクエスト
4. 認証
レスポンス
（ID情報 or
「引換証」）
ID情報
提供側
ID情報
要求側
ユーザー
1. アクセス
試行
5. サービス
提供
3. 認証・同意
4’
4’. 「引換
証」を送信
4’’
4’’. 認証
レスポンス
（ID情報）

OpenID Connect
リライング・パーティ
(RP: ID情報要求側)
Webアプリ
ケーション
モバイル
アプリケーション
ライブラリや
パッケージの導
入が不要
ネイティブ
(non-Web)
アプリでも
利用可能
認証結果/属性情報提供
JWT * によって
セキュアにID情報を提供
* JSON Web Token
アイデンティティ・プロバイダ
(IdP: ID情報提供側)
SSO / アクセス
管理システム
“Self-issued IdP”
OpenID
Connect
対応製品が
続々登場
携帯端末が
IdPに!
 OAuth 2.0仕様をベースに「アイデンティティ層」を拡張し、
認証結果や属性情報の連携、セッション管理などのAPIを標準化
認可リクエスト/APIアクセス
OAuth 2.0による
API認可と統合

主要ID/API連携仕様がすべてOpenID Connectに収斂
Source: http://civics.com/OpenID-connect-webinar/
セキュリティ・
アサーション
JSON形式の
「IDトークン」
サービス発見
シンプル、APIとの親和性、
モバイル対応
動的なクライント
登録

アイデンティティ連携関連仕様の比較
比較項目＼仕様 SAML 2.0 OpenID 2.0 OAuth 2.0 OpenID Connect
ID受け入れ側（リライング・
パーティ）の実装・運用の容
易さ
×（XMLやSOAP、PKIなどのスキルが必要
であり、通常はSAML処理ライブラリやミ
ドルウェアの導入が必須）
△（鍵交換や署名処理が必要であり、通
常はOpenID処理ライブラリなどの導入
が必須）
○（ライブラリ等の導入が不要） ○（ライブラリ等の導入が不要）
Webブラウザ以外（デスク
トップアプリ、スマートフォ
ンアプリなど）への対応
△（仕様上はWebブラウザ以外にも対応可
能だが、実際に広く利用されているのは
Web SSOのみ）
×（Webブラウザのリダイレクト機能に
依存したプロトコルであり、Webブラウ
ザ以外への対応は不可能）
○ ○
認証結果の連携 ○ ○ ×（仕様外であり、OAuth採用事業者の
独自拡張が乱立）
○
属性情報の連携 ○ ○ ×（仕様外であり、OAuth採用事業者の
独自拡張が乱立）
○
APIアクセス認可（アクセス
トークン配布）への対応
×（仕様のスコープ外） △（OAuth 1.0とのハイブリッドにより
対応）
○ ○
複数のアクセストークンへの
対応
×（仕様のスコープ外） ×（仕様のスコープ外） ×（仕様のスコープ外） ○
認証結果・属性情報への署名
や暗号化
○ △（共有鍵による署名のみ可能。暗号化
は仕様のスコープ外）
×（そもそも、認証結果・属性情報の連
携は仕様のスコープ外）
○
サイト間のセッション管理 ○ ×（仕様のスコープ外） ×（仕様のスコープ外） ○
機能の不十分なWebブラウザ
（携帯電話等）への対応
× × ○ ○
備考さまざまなユースケースに適用可能な仕様
であるが、それゆえに複雑であり、結果的
には企業内ID管理システムと企業向けSaaS
との間でのSSOに利用されるにとどまって
いる。
Webサイト間の認証結果・属性情報の交
換に特化したプロトコルであり、従前の
仕様（SAML 2.0)に比較して単純なプロ
トコルであるが、鍵交換や署名処理など、
まだ実装が容易ではない点が残る。
OAuth 1.0をベースに、より容易に実装
できるように仕様を簡略化。Web APIの
アクセス認証プロトコルとして広く普及。
しかしD連携に関してはスコープ外であ
り、独自仕様が乱立している。
OAuth 2.0をベースに、ID連携のためのプ
ロトコルを定義。OAuth 2.0の実装のしや
すさを活かしつつ、ID連携に十分な機能を
定義している。

OpenID ConnectによるID連携のしくみ
 ユーザーの認証イベント
（認証結果）を「IDトークン」
として定義
 OAuth 2.0と同一のフローにて、
「アクセストークン」に加え、
新たに「IDトークン」の要求・
提供を定義
 また、属性情報を提供する
「ユーザー情報（UserInfo）
API」を定義
1
2 4
3
7
2. 認可
リクエスト ID情報
提供側
（アイデン
ティティ・
プロバイ
ダ）
ID情報
要求側
（リライン
グ・パー
ティ）
ユーザー
1. アクセス
試行
7. サービス
提供
3. 認証・
同意
4’
4’. 「認可
コード」を
送信
4’’
トークン」
4. 認可
レスポンス
or 「アクセス
トークン」
「IDトークン」）
5
5. UserInfo
アクセス
with アクセ
ストークン
6
6. 属性
情報

IDトークン
 ID情報提供側におけるユーザ認証イベントの情報を
含む、署名付きJWT（Signed JSON Web Token）
 「このエンドユーザーは○○で、何時何分に、こういう
方法で認証を受け、認証レベルは○で、…」
 ID情報要求側は主に、IDトークンに含まれる以下の
クレーム（ID情報提供側がユーザーに関して表明
する情報）を用いて、エンドユーザーのアクセス
認可を行う
 エンドユーザーを識別する値（識別子）
 IDトークンの有効期限
 ユーザ認証を実施した日時
 認証コンテクスト・クラス・リファレンス
 認証手段リファレンス
 その他（ユーザー属性など）
{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"gender": "female",
"birthdate": "0000-10-31",
"email": "janedoe@example.com",
"picture": "http://example.com/janedoe/me.jpg"
}
IDトークンの中身の例
1
2 4
3
7
2. 認可
リクエスト ID情報提供側
（アイデン
ティティ・
プロバイダ）
ID情報
要求側
（リライン
グ・パー
ティ）
ユーザー
1. アクセス
試行
7. サービス
提供
3. 認証・
同意
4’
4’. 「認可コード」
を送信
4’’
トークン」
4. 認可
レスポンス
or 「アクセス
トークン」
「IDトークン」）
5
5. UserInfo
アクセス
with アクセス
トークン
6
6. 属性情報

OpenID Connect仕様の現状と今後
 2014年2月に「OpenID Connect」仕様の最終版が承認
 コア機能、ディスカバリー、動的クライアント登録など
 最終版の承認以前から、すでに複数の製品・サービスがOpenID Connectを実装済み
 製品: 野村総合研究所（Uni-ID）、日本電気（NC7000-3A)、NTTソフトウェア（TrustBind
Federation Manager）、Ping Identity （PingFederate）、Gluu (OX)、CA (Layer 7)、
ForgeRock (OpenAM)
 サービス: Yahoo! JAPAN (YConnect)、日本経済新聞社（日経ID）、東急電鉄、テレビ東京、
Google、PayPal (Log In with PayPal)、東芝 (Cloud TV) 、ソフトバンクモバイル (My
SoftBank)、ミクシィ、Salesforce.com、Microsoft
 その他、セッション管理などの関連仕様が、最終版を目指して策定中

仕様の最終版承認を受け、主要IDプロバイダーにおいて
OpenID Connectへの移行が活発化
 Google: 従来の自社独自の認証認可仕様を非推奨とし、
OpenIDとOAuthに移行。さらに将来的にはこれらを廃止し
てOpenID Connectに統一することを表明
 Salesforce.com: 従来のSOAP APIは自社独自の認証認可仕
様を用いていたが、新たなRESTful APIはOAuthとOpenID
Connectに統一
 PayPal: 従来のAPIは自社独自の認証認可仕様を用いていた
が、OpenID、OAuth、OpenID Connectに移行中。この中で
もとくにOpenID Connectの利用を推奨
 Microsoft: これまでは自社が中心となって策定したWS-
Federationの普及を目指していたが、今後の主力サービスで
あるWindows LiveやWindows AzureにはOAuthを採用。
OpenID Connect対応が進行中
… we’re also going to consolidate all our
federated sign-in support onto the OpenID
Connect standard. … we will deprecate
support for our older federated sign-in
protocols including OpenID 2.0 on April 20,
2015, and our early version of OAuth 2.0
for Login, including the userinfo scopes and
endpoint, on September 1, 2014.
Googleは2015年4月までにOpenID
Connect以外のIDの連携APIを終了予定
Source: Google Developer Blog

ID管理・ユーザー認証・属性提供のサービス化
(IDaaS; Identity as a Service)
ユーザー
“IDaaS”
•Google
•Microsoft
•Salesforce.com
•PayPal
•…
サービス
OpenID Connectに
よって認証を依頼
IDプロバ
イダーの
IDでログ
イン
サービス
利用
IDプロバイダーにユーザー認証を委ねる
ことにより、自前で行なうよりも
より高度な不正アクセス対策が活用できる
ふだん使い慣れているID
でサービスが利用可能に
なり、利便性が向上し、
またサービスへの
パスワード登録が不要と
なることもユーザーの
不安の解消につながる
IDaaS活用の
業界標準API =
OpenID
Connect

まとめ
 ユーザー認証強化をビジネスを考慮しつつ
効率的に実現するためには、
ID（アイデンティティ）連携が有効
 ID連携技術の標準はこれまで複数存在
していたが、業界はOpenID Connectへの
統一に向かっている
 今後はOpenID Connectによる
ユーザー認証の外部化も選択肢のひとつに

リソース
 OpenIDファウンデーション・ジャパン
http://www.openid.or.jp/
 OpenID関連情報の提供やセミナーの開催
 会員企業同士の活動
▪ワーキンググループを通じた、業界イニシアティブへの参画
▪企業や業界を超えた標準仕様の作成や、ビジネスモデルの創出に関する検討
▪IDを軸とする会員企業間のコラボレーション
▪技術者コミュニティや会員企業間の情報交換を通じた、OpenID関連の技術情報、
ビジネストレンド情報の入手
▪会員企業限定のセミナー、交流会（ネットワーキング）、フォーラムへの参加

パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～

Similar to パスワード氾濫時代のID管理とは？～最新のOpenIDが目指すユーザー認証の効率的な強化～ (20)

More from Tatsuo Kudo

More from Tatsuo Kudo (20)

Recently uploaded

Recently uploaded (8)