パスワード氾濫時代のid管理とは？...

工藤達雄

OpenIDファウンデーション・ジャパン

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

アジェンダ

不正アクセス対策としての「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アプリケーションのユーザー認証・認可」を

シーケンスとして考えてみる

2. 「ログインしてください」

3. ID/パスワードを入力

1. アクセス試行 4. ID/パスワード

を照合

アプリケーション

ID情報

ユーザー

5. 照合OK

（属性を返却） 7. ユーザーに応じたサービスを提供 8. アクセス試行

（ログイン済み）

9. ユーザーに応じたサービスを提供

6. アクセス

認可決定

サービスが個別にユーザー認証・認可を行なう

アプリ

ケーションA

ID情報

ユーザー 6

ID情報

8 アプリ

ケーションB

事業者による個別対応は、ユーザーの利便性をさらに下げることに

3. ID/パスワード、OTP、…

アプリ

ケーションA

ID情報

DB ユーザー

10. ID/パスワード、厳しいパスワードポリシー、…

ID情報

8 アプリ

ケーションB

ユーザー認証

プロセス、

パスワードポリシー、

認証に必要な

デバイスの

管理などが、

サイトごとに

バラバラ

アイデンティティ&アクセス管理（IAM）システムを導入し、ユーザー認証・認可を一元化する

アプリ

ケーションA

ID情報

DB ユーザー

8 アプリ

ケーションB

4. ID/パスワードを照合

5. 照合OK

（属性を返却）

6. アクセス

認可決定

IAMシステム

1. アクセス試行

IAMの利点と限界

効率的にセキュリティの向上を図ることができる

タイムリーなアカウント改廃、サービス全体を統一するユーザー認

証・認可、パスワードポリシー、不正アクセス検知機能などの統合

ユーザーにとっての利便性が高まる

シングル・サインオン、プロファイル情報の共通化

しかし、基本的には同一企業グループ内でしか使えない

グループ企業であっても、ビジネス的に統合できないケースも

「一元化」のアプローチは魅力的だが、事業ドメインが異なるサービスに対しては容易に適用できない

アプリ

ケーションA

アプリ

ケーションB

ID情報

ユーザー

ビジネス関係や法規制等の制限から、ID情報を

共通化することは難しい

ID情報

ID（アイデンティティ）連携:

ユーザーの同意にもとづくID情報の要求・提供

アプリ

ケーションA

アプリ

ケーションB

ID情報

ユーザー

ID情報

2. 認証

リクエスト 11. 認証

レスポンス

（ID情報）

5. ID/ パスワードを

照合 6. 照合

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（オープンアイディー・コネクト）

2. 認証

リクエスト

4. 認証

レスポンス

（ID情報 or

「引換証」）

ID情報

提供側

ID情報

要求側

ユーザー

5. サービス提供

3. 認証・同意

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向けのプロファイル

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)

ユーザー

3. 認証・

同意

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/PW等）の入力によるユーザの特定はOP側で行うため、RP側にクレデンシャル情報を流通させる必要がない

OP：ID情報の提供側 RP：ID情報の受入側

OpenID Authentication 2.0

3. 認証

リクエスト ID情報

提供側

(OpenID

Provider)

ID情報

要求側

(Relying

Party)

ユーザー

4. 認証・

同意

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連携プロトコルの一つとして採用

Source: http://oauth.net/2/

ユーザーの代理としてWeb APIにアクセスするクライアントのアクセス認可をどのように実現するか

「ユーザーのID/パスワード」を預かる

方法が広まってしまったが…

ユーザーはサービスBのID/パスワードを

サービスAに漏らしている

▪サービスAの情報漏えいや、サービスA自身に

よる不正利用の懸念が残る

ユーザーはサービスAに全権委任する

かたちに

▪サービスAは本来不要な（過剰な）API

アクセスを行うこともできてしまう

使い勝手が悪い

▪サービスBのID/パスワードを変更すると、

サービスAがアクセスできなくなる

▪サービスAからサービスBへのアクセス可能

期間を指定できない

サービスB

（API提供側）

サービスA

（API利用側）

ユーザー

1. サービスBにある自身のコンテンツを参照するために、ユーザーがサービスBに

おけるID/パスワードを提供

4. サービスBの

コンテンツを

もとにサービス

を提供

2. サービスAが、サービスBのID/

パスワードを用いて代理ログインし、

APIにリクエストを送信

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 提供側はユーザー単位での

アクセス管理が可能

▪トークンはユーザーとひもづいている

2. 認可

リクエスト認可

サーバー/

リソース

サーバー

API クライ

アント

ユーザー

3. 認証・同意

4’. 「認可コード」を

送信

4’’

4’’. 「アクセストークン」

4. 認可

レスポンス

（「認可コード」

or 「アクセストークン」）

5. API アクセス

with アクセストークン

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"

アクセストークン（レスポンス）の例

2. 認可

リクエスト認可

サーバー/

リソース

サーバー

API クライ

アント

ユーザー

3. 認証・同意

4’. 「認可コード」を送信

4’’

4. 認可

レスポンス

or 「アクセス

トークン」）

5. API アクセス

6. APIレスポンス

最新のID連携仕様

“OpenID Connect”

SAML、OpenID、OAuthではダメなのか!? Pros Cons

SAML •仕様がモジュール化されており、拡張性が高い

•署名や暗号化などを用いてセキュリティを強化できる

•仕様群が膨大

•XMLの検証や署名、暗号化などが複雑であり、実装が容易ではない

•RESTful APIとはなじまない

OpenID •認証結果と属性情報の要求・提供に機能を限定して標準化されており、相互接続性が高い

•鍵共有、署名の付与・検証が面倒

•平文のID情報がWebブラウザ経由で流れるため、内容が露見

•APIアクセス認可への応用は不可能

OAuth •他の仕様と比較してシンプル

•スコープによるアクセス権限指定、Authorizationヘッダの利用など、「RESTful API」との親和性が高い

•Webブラウザだけではなく、モバイルネイティブやJavaScriptなど、モダンなクライアント環境を考慮している

•認証結果と属性情報の要求・提供が定義されておらず、事業者の独自拡張が乱立

2. 認証

リクエスト

4. 認証

レスポンス

（ID情報 or

「引換証」）

ID情報

提供側

ID情報

要求側

ユーザー

3. 認証・同意

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」を定義

2. 認可

リクエスト ID情報

提供側（アイデンティティ・プロバイダ）

ID情報

要求側（リライング・パーティ）

ユーザー

3. 認証・同意

4’. 「認可

コード」を

送信

4’’

4. 認可

レスポンス

or 「アクセストークン」

「IDトークン」）

5. UserInfo アクセス

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トークンの中身の例

2. 認可

リクエスト ID情報提供側（アイデンティティ・

プロバイダ）

ID情報

要求側（リライング・パーティ）

ユーザー

3. 認証・同意

4’. 「認可コード」を送信

4’’

4. 認可

レスポンス

or 「アクセス

トークン」

「IDトークン」）

5. UserInfo アクセス

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管理とは？...

Technology

（内水氾濫）土砂災害の兆候...

添付資料-4-1 規模別の氾濫解析結果図...

令和2年7月豪雨及び...

2020年7月28-29日最上川沿岸氾濫地図と写真 -...

web fairy paradise1 web fairy paradise 0...

iot...

title...

下新川海岸の概要 -...

災害時 · web...

添付資料-4-4 規模別の氾濫解析結果図 huallaga...

gisを用いた氾濫解析データの作成と飯塚市街地を...

チャオプラヤ川流域における...

3 氾濫シミュレーションにおける...

目...

分布型降雨流出氾濫モデルrriと...

氾濫ブロック図 - mlit...水無川 7.4 5,485 1,820...

ダム関係の費用便益比（b／c）算定等資料 ·...

此花区における水害ハザードマップ -...

title...

添付資料-4-7 規模別の氾濫解析結果図...