Upload
tatsuo-kudo
View
5.660
Download
10
Embed Size (px)
Citation preview
工藤達雄
OpenIDファウンデーション・ジャパン
パスワード氾濫時代のID管理とは? ~最新のOpenIDが目指すユーザー認証の効率的な強化~
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
アジェンダ
不正アクセス対策としての「ID連携」
ID連携技術概要(SAML、OpenID、OAuth)
最新のID連携仕様 “OpenID Connect”
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
自己紹介
工藤達雄 http://www.linkedin.com/in/tatsuokudo, @tkudos
サン・マイクロシステムズ (1998~2008) https://blogs.oracle.com/tkudo
野村総合研究所 (2008~)
OpenIDファウンデーション・ジャパン
(2013~)
http://openid.or.jp/blog
不正アクセス対策としての
「ID連携」
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
パスワード管理は限界にきている
3種類以下のパスワードを使いまわすユーザが約7割 /
2人に1人はパスワードを変更する習慣なし
Source: トレンドマイクロ、2012年12月14日発表
自分のIDでログインして利用するサイトの数は平均19.40 / 記憶できるIDとパスワードの組み合わせは平均3.15
Source: 野村総合研究所、2012年2月8日発表
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
急増するパスワードリスト攻撃
自分の運営するサイトでは
適切にID管理をしていても
ユーザーがID/パスワードを
使いまわしているために
弱いサイトから漏れて
しまう
Source:情報処理推進機構
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
ユーザー側に負担
対策として「サイトごとにパスワードを
変える」
本当に可能だろうか?
パスワードマネージャーの導入
サイトごとのパスワードを自動生成し、
ログインを支援するツール
ブラウザの標準機能としてサポートする
ケースも出てきたが…
→ いずれもユーザー側に対応を求めている
「個人の利用者がパスワードリスト
攻撃による最終的な被害者に
ならないようにするためには、
すべてのインターネットサービスで
異なるパスワードを設定する必要が
あります」
Source: 情報処理推進機構
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
事業者側の対策の動向
2要素認証
大手サイトが相次いで導入している
しかし2要素認証を行なうサイトが多数乱立するようになると
ユーザーにとっては不便
リスクベース認証
不正アクセスかどうかを判定し、必要に応じて高度認証を実施
→ サービス側の導入・運用が容易ではない
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
「Webアプリケーションのユーザー認証・認可」を
シーケンスとして考えてみる
1
2
3
7
4
5
8
9
2. 「ログインしてください」
3. ID/パスワードを入力
1. アクセス試行 4. ID/パスワード
を照合
アプリケーション
ID情報
DB
ユーザー
5. 照合OK
(属性を返却) 7. ユーザーに応じたサービスを提供 8. アクセス試行
(ログイン済み)
9. ユーザーに応じたサービスを提供
6
6. アクセス
認可決定
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
サービスが個別にユーザー認証・認可を行なう
2
3
7
4
5
3. ID/パスワードを入力
アプリ
ケーションA
ID情報
DB
ユーザー 6
1
9
10
14
11
12
10. ID/パスワードを入力
ID情報
DB
13
8 アプリ
ケーションB
2. 「ログインしてください」
9. 「ログインしてください」
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
事業者による個別対応は、ユーザーの利便性をさらに下げることに
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
ユーザー認証
プロセス、
パスワードポリシー、
認証に必要な
デバイスの
管理などが、
サイトごとに
バラバラ
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
アイデンティティ&アクセス管理(IAM)システムを導入し、ユーザー認証・認可を一元化する
2
3
7
4
5
アプリ
ケーションA
ID情報
DB ユーザー
6
1
9
3. ID/パスワードを入力
8 アプリ
ケーションB
2. 「ログインしてください」
4. ID/パスワードを照合
5. 照合OK
(属性を返却)
6. アクセス
認可決定
IAMシステム
1. アクセス試行
7. ユーザーに応じたサービスを提供
8. アクセス試行
9. ユーザーに応じたサービスを提供
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
IAMの利点と限界
効率的にセキュリティの向上を図ることができる
タイムリーなアカウント改廃、サービス全体を統一するユーザー認
証・認可、パスワードポリシー、不正アクセス検知機能などの統合
ユーザーにとっての利便性が高まる
シングル・サインオン、プロファイル情報の共通化
しかし、基本的には同一企業グループ内でしか使えない
グループ企業であっても、ビジネス的に統合できないケースも
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
「一元化」のアプローチは魅力的だが、事業ドメインが異なるサービスに対しては容易に適用できない
アプリ
ケーションA
アプリ
ケーションB
ID情報
DB
ユーザー
A社
B社
ビジネス関係や法規制等の制限から、ID情報を
共通化することは難しい
ID情報
DB
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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
3. 「ログインしてください」
4. ID/パスワードを入力
1. アクセス試行
2. 認証
リクエスト 11. 認証
レスポンス
(ID情報)
5. ID/ パスワードを
照合 6. 照合
OK
9. 属性取得
10. 属性提供
7. 「ID情報
提供OK?」
8. ユーザーによる同意
15. ユーザーに
応じた
サービスを提供
12. 認証レスポンスに基づきユーザーを特定し属性情報を要求
13. 属性取得
14. アクセス認可決定
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
ID(アイデンティティ)連携のポイント
ID情報(認証結果、属性情報)が連携される
パスワードのような秘密情報は流れない
ユーザーの同意に基づいて行われる
サービス同士が勝手にやりとりするのではない
各サービスの独立性が保たれる
外部から取得したID情報を用いてどのようにアクセスを認可するかは各サービスの判断に
委ねられる
→ システム的にもビジネス的にも有利
ID連携技術概要
(SAML、OpenID、OAuth)
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
SAML (サムル; Security Assertion Markup Language)
アイデンティティ情報を安全に
流通させるためのXML形式
および通信仕様
ID連携を実現する主要要素を
4つに分解
「アサーション」「プロトコル」
「バインディング」「プロファイル」
Profile 特定のユースケース(SSOなど)を実現するうえでの、
アサーション、プロトコル、バインディングの
組み合わせを規定。
Binding リクエストおよびレスポンスの手続きを、実際にIdP
とRPの間でどのように実施するか規定。直接通信(SOAP)や、ユーザエージェントを介在させる
HTTPリダイレクト通信などが存在。
Protocol アサーションの送受信を実施するための
リクエストおよびレスポンスの手続き。
Assertion ユーザのID名や認証方法およびそのユーザの
属性や権限に関する表明。
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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">[email protected]</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 「アーティファクト」)
アサーションの例
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
SAMLの代替としてのOpenIDの登場
「Webサイト間のID連携」に特化し、Webサイト開発者
にとって使いやすい仕様にした
SAMLは包括的なフレームワークであるがゆえに複雑
「ユーザーセントリック・アイデンティティ」(ユーザー
によるID連携のコントロール)を仕様に盛り込んだ
SAMLは事業者中心のモデル
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
「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)
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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情報の受入側
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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. アサーション(一部略)
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
OpenID 2.0の普及動向
多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するた
めの API(Application Programming Interface)としてOpenIDを採用
インターネットサービス事業者(例: Yahoo!、Google、ミクシィ)
携帯通信事業者(例: NTTドコモ、KDDI、ソフトバンク)
ネット決済事業者(例: 楽天(楽天あんしん支払いサービス)、PayPal)
公共性の高いサービスでのOpenIDの採用
米国において、民間のIdP (Identity Provider:たとえばポータル事業者や決済事業
者など、市民に対してID を発行・運用する組織)と、連邦政府機関の市民向けWeb
サイトとのID連携プロトコルの一つとして採用
Source: http://oauth.net/2/
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
ユーザーの代理として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のユーザーであるとみなし、処理結果を返却
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
OpenIDをAPIのアクセス認可にも使えないか?
2006年11月、TwitterのエンジニアやOpenIDコミュニティを
中心に、API代理認証にOpenIDを適用できないか議論が
始まった。結果的にOpenIDは適用できず、また当時API代理
認証のオープン標準と呼べるものはまだ存在しないことが
明らかになった。
2007年4月、少人数にてプロトコル検討が始まり、7月には
仕様草案の初版をもとに公開の場にて議論されるように
なった。そして10月、OAuth 1.0の最終ドラフトが公開された。 Source: http://oauth.net/about/
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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レスポンス
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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、…
スマートグリッド: 会津若松スマートシティ推進協議会
その他多数
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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’’. 「アクセストークン」
4. 認可
レスポンス
(「認可コード」
or 「アクセス
トークン」)
5
5. API アクセス
with アクセストークン
6
6. APIレスポンス
最新のID連携仕様
“OpenID Connect”
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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情報)
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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認可と統合
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
主要ID/API連携仕様がすべてOpenID Connectに収斂
Source: http://civics.com/OpenID-connect-webinar/
セキュリティ・
アサーション
JSON形式の
「IDトークン」
サービス発見
シンプル、APIとの親和性、
モバイル対応
動的なクライント
登録
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
アイデンティティ連携関連仕様の比較 比較項目 \ 仕様 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連携に十分な機能を定義している。
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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’’. 「アクセストークン」
「IDトークン」
4. 認可
レスポンス
(「認可コード」
or 「アクセストークン」
「IDトークン」)
5
5. UserInfo アクセス
with アクセストークン
6
6. 属性情報
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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": "[email protected]",
"picture": "http://example.com/janedoe/me.jpg"
}
IDトークンの中身の例
1
2 4
3
7
2. 認可
リクエスト ID情報提供側 (アイデンティティ・
プロバイダ)
ID情報
要求側 (リライング・パーティ)
ユーザー
1. アクセス試行
7. サービス提供
3. 認証・同意
4’
4’. 「認可コード」を送信
4’’
4’’. 「アクセストークン」
「IDトークン」
4. 認可
レスポンス
(「認可コード」
or 「アクセス
トークン」
「IDトークン」)
5
5. UserInfo アクセス
with アクセストークン
6
6. 属性情報
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
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
その他、セッション管理などの関連仕様が、最終版を目指して策定中
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
仕様の最終版承認を受け、主要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
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
ID管理・ユーザー認証・属性提供のサービス化 (IDaaS; Identity as a Service)
ユーザー
“IDaaS”
•Microsoft
•Salesforce.com
•PayPal
•…
サービス
OpenID Connectによって認証を依頼
IDプロバイダーのIDでログイン
サービス利用
IDプロバイダーにユーザー認証を委ねる
ことにより、自前で行なうよりも
より高度な不正アクセス対策が活用できる
ふだん使い慣れているID
でサービスが利用可能に
なり、利便性が向上し、
またサービスへの
パスワード登録が不要と
なることもユーザーの
不安の解消につながる
IDaaS活用の
業界標準API =
OpenID
Connect
まとめ
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
まとめ
ユーザー認証強化をビジネスを考慮しつつ
効率的に実現するためには、
ID(アイデンティティ)連携が有効
ID連携技術の標準はこれまで複数存在
していたが、業界はOpenID Connectへの
統一に向かっている
今後はOpenID Connectによる
ユーザー認証の外部化も選択肢のひとつに
Copyright © 2014 OpenID Foundation Japan. All Rights Reserved.
リソース
OpenIDファウンデーション・ジャパン http://www.openid.or.jp/
OpenID関連情報の提供やセミナーの開催
会員企業同士の活動
▪ワーキンググループを通じた、業界イニシアティブへの参画
▪企業や業界を超えた標準仕様の作成や、ビジネスモデルの創出に関する検討
▪IDを軸とする会員企業間のコラボレーション
▪技術者コミュニティや会員企業間の情報交換を通じた、OpenID関連の技術情報、
ビジネストレンド情報の入手
▪会員企業限定のセミナー、交流会(ネットワーキング)、フォーラムへの参加