アイデンティティ2.0とOAuth/OpenID Connect

©Copyright 2014 Mashmatrix, Inc. All rights reserved.
アイデンティティ2.0と
OAuth/OpenID Connect
Mashmatrix, Inc.
www.mashmatrix.com
!
Shinichi Tomita
stomita@mashmatrix.com

この資料は、株式会社ウフル (http://uhuru.co.jp/) の
社内セミナーにて使用した資料です。ウフル様のご好意
により、公開の許諾を得ましたので、公開いたします。
!

前回のおさらい
• シングルサインオンがなぜ必要か
• 認証・認可
• SAML

200X年は
コンシューマWebの時代

Weblog（ブログ）の隆盛
• 2000年代前半、ブログによって誰でもカジュアルにWeb
へコンテンツ発信が可能に
• MovableTypeなどのソフトウェア、RSSなどの発展
• 発生した問題
• ブログのコメント記入にスパムが多くなった。
• スパム回避のために、コメントする人の出自を明らかにしたい
• でも数あるブログサイトにコメントする人全員のログインアカ
ウントを作る？無理無理。

解決策とOpenIDの誕生
• もうみんなWebのどこかに自分のサイト（ブログ）を
持ってるよね？
• コメント主にはそのサイトの持ち主が自分であることを証
明してもらったらいいんじゃない？
• Webのような分散した環境でも自分のアイデンティティ
を伝達できる仕組み（プロトコル）をつくろう！
• 2005年頃、Six ApartのメンバーがOpenID 1.0を提唱

OpenIDの特徴
• World Wide Web、分散環境が大前提
• 誰でも自分のサイトでアイデンティティを主張できる
• どのサイトでも自分のアイデンティティを利用できる
• 最初から「シングルサインオン」を求めたわけではない
• コメントするユーザの所有するWebサイトを識別することが最初の動機
• ユーザのアイデンティティはインターネット上にURLでアクセス可能であ
る、という想定
• OpenID 2.0でシングルサインオン用途にも利用できるように拡張
• サイトを事前に登録したりする必要はない
• 動的なディスカバリが仕様に含まれる

参考：User-Centric Identity
• サイト中心のアイデンティティ（Identity 1.0）
• ユーザのアイデンティティはサイトが管理する
• アイデンティティのサイロ(Silo)／壁に閉ざされた庭(Walled
Garden）
• ユーザ中心のアイデンティティ（Identity 2.0）
• 利用者本人がアイデンティティ情報をコントロールする

Identity 2.0
• 高速プレゼンテーションスタイルで有名
• https://www.youtube.com/watch?
v=RrpajcAgR1E
• ActiveState、SXIP創業者
• Chuck Mort（現SFDC Identity PM）は
元SXIPに在籍していたことも
• SXIPのクローズ後、Microsoftを経て、現在
フリー？
Dick Hardt

マッシュアップとOAuth
• WebサービスAPIを利用した「マッシュアップ」の流行
• パブリックなリソースだけでなく、アクセス保護されたリソースも扱いたい
• 代理アクセスの必要性・権限の委譲
• OAuth1.0: Webアプリの認可のためのプロトコルを標準化
• Flickrなどで利用されていた権限委譲の仕組みがヒント
• スコープによって委譲する権限を指定可能
• 例：読み込みのみ／書き込み可／プロフィール情報のみ／コンタクト情報も可、など
• 現在もTwitterのAPIはOAuth1.0aで提供されている
• なお1.0にはプロトコルに脆弱性が見つかっているため、現在は改訂版の1.0aを使う
べき

Facebook Connect
• Facebookの独自仕様で展開されたAPI接続の仕組み
• Webサイトから簡単にFacebookのサービスに接続するた
めのウィジット・ボタンを用意
• サーバサイドいらず、Webサイトにファイルを置くだけで導入
できる簡単さ
• JavaScript SDKもあり、複雑なアプリの構築も可能
• Facebookの爆発的な普及により、多数のサイトで使われ
るように

OAuth 2.0
• OAuth 1.0の反省
• セキュリティ維持のため複雑になってしまったプロトコル
• 電子署名の扱いに苦労する開発者
• OAuth 2.0
• Facebook Connectを参考にして、Dick HardtらがOAuth WRAPを提
唱 OAuth 2.0へ進化
• 署名のような面倒な手間を省き、セキュリティはSSLで保証する
• Facebookも後にOAuth2.0に合わせてAPIを変更
• Secret情報を持つことが難しいJavaScriptやスマホアプリからも利用
できるImplicit Grant Flowも

OAuth 2.0 
(Authorization Code Flow)
http://www.atmarkit.co.jp/ait/articles/1209/10/news105.html

OAuth 2.0 
(Implicit Grant Flow)

ソーシャルログイン？
• 「既に外部のソーシャルサービスに保有しているアイデン
ティティを利用して、ユーザが（サイト｜アプリ）にログ
インできる機能」に対する俗称
• 「アイデンティティ連携(Identity Federation)」という語が一
般開発者には直感的でなかったことも原因か
• 実際はOAuthなどでソーシャルAPIへのアクセス権限を取得 
ユーザの識別情報を取得して「ログイン」

OAuthによる 
「ソーシャルログイン」の課題
1. 標準化されていない
• ユーザ情報はサービス独自のAPIを利用して取ってくる
• 接続するサービスごとにクライアントの開発が必須
2.『認可』を『認証』に利用
• APIに対するアクセスの認可を与えられたとしても、そのAPIから得たユーザ情報をユー
ザの認証に利用してほんとにいいのか？
3. API権限を悪用したスパム
• そもそもログインしたいだけなのに、なぜアクセス権限が必要なの？
4.（原理主義的には）ユーザー・セントリックでない
• 外部のアイデンティティを選択できるという意味ではユーザー・セントリックだが、
ユーザが任意のアイデンティティを持ち運べるわけではない

OpenID Connect
• 広く普及したOAuth2.0をベースにした、分散環境でユー
ザのシングルサインオンを実現するためのプロトコル
• 売り文句：
• OAuth2を使った認証よりも標準化されており安心
• SAMLより簡単なので実装は容易

OpenID Connect の特徴
• アイデンティティ情報を取得するためのスコープ openid を定義
• UserInfo Endpoint というユーザ情報を取得するAPIのスキー
マを定義し、インターフェースを統一
• 従来のaccess_tokenの他に id_token というトークンを定義
• ユーザのアイデンティティを証明する（アサーション）トークン
• JWT（JSON Web Token）を利用し、電子署名で改ざんを防止
• UserInfo EndpointがFirewall内にある場合や、複数アプリをまたがって
トークンが伝達される場合などに活用可能
• OpenID 2.0と同様に動的にサイト間の連携を行う仕組みもあり
（関連仕様）

OpenID Connectのフロー

まとめ
• 企業システムを中心としたシングルサインオンの発展とは別
に、コンシューマWebにおける要求からOpenIDおよび
OAuthが生まれた
• OAuthは、成功したFacebook Connectを参考に、より簡潔
さを重視したOAuth2.0へと発展した
• Facebook/Twitterの台頭により、外部アイデンティティを利
用したログインという体験は一般化したが、一方でさまざま
な問題を孕んだ
• OpenID Connect による標準化で連携はもっと楽になるかも

演習(OpenID Connect)
• OpenID Connect を利用して、SalesforceをGoogleアカウ
ントでログインできるようにする
• 参考URL：
• http://blog.flect.co.jp/salesforce/2014/06/openid-connect-affa.html
• ＜発展演習＞：上記の連携で取得したTokenを利用して、Apex
からGoogleのAPIを叩いてみる
• 参考URL：
• http://www.tquila.com/blog/2014/02/13/accessing-google-apis-
apex-minimal-effort

アイデンティティ2.0とOAuth/OpenID Connect

More Related Content

アイデンティティ2.0とOAuth/OpenID Connect