1

LangEdge,Inc.

今更聞けない電子認証入門
OAuth 2.0 / OIDC から FIDO まで＜改定２版＞

プログラマ/取締役
宮地直人（miyachi@langedge.jp）

２０２０年９月２９日

2LangEdge,Inc.

LE miyachi
⼈と⾔うエンティティ（実体）は様々なアイデンティティとIDを持つ。
AITC クラウド部会 メンバー
マイナンバー：〇〇〇〇〇〇
氏名：宮地 直人、性別：男
住所：東京都江戸川区〇〇〇
生年月日：１９〇〇年２月〇日

有限会社ラング・エッジ
プログラマ／取締役
社員番号：0002
miyachi@langedge.jp
PKI・PDF系製品開発等
https://www.langedge.jp/

OpenIDファウンデーション・ジャパン
会員企業
https://www.openid.or.jp/
オープンソース署名＆認証ラボ
OsSAL SAL No.0001
勉強会・オープンソース開発
https://www.ossal.org/

JIIMA 会員
Twitter@le_miyachi
JT2A / JNSA
電子署名WG所属
標準化 ISO TC 154
http://eswg.jnsa.org/

https://www.slideshare.net/lemiyachi
https://github.com/miyachi/

Facebooknao.miyachi

LangEdge,Inc.

3

１．認証入門：ID・アイデンティティ・認証
２．認証基本：NIST SP 800-63-3
３．認証利用：OAuth 2.0・OpenID Connect
４．認証応用：PKCE・FIDO2

LangEdge,Inc.

4

ID と アイデンティティ（Identity）
ID︓１つの実体（エンティティ）に付す識別⼦となる属性情報
Identity︓実体（エンティティ）に関する属性情報の集合 IDとはIdentityの持つ属性情報の１つで識別に利⽤する。
 １つの実体は、複数のID/Identityを持つことができる。
 ⼈は実体をIdentity（属性の集合）を通じて認識する。
Authentication/AuthN（認証）︓

端末の前にいる実体がサービス側が認識するどのIdentityと紐付いているかの確証を得ること。

Authenticator（認証器/認証コード）︓Credential（信⽤）情報を扱う

Authorization/AuthZ（認可）︓

端末の前にいる実体のIdentityがサービス側が提供するリソースにアクセスをする権限を持っているか確認すること。

Access Control＝AuthN＋AutnZ＋Audit [logging]LangEdge,Inc.

5

本人確認（Identity Proofing） と 当人確認（認証）Onbording（登録時）のアカウントID登録時には、
Identity Proofing（本⼈確認）が必要
 Identity Proofing︓属性情報の確かさを確認する
例︓メール到達・運転免許書・マイナンバーカード等を利⽤

 KYC（Know Your Custorer）も本⼈確認

サービス事業者のための、本⼈確認⼿続き（KYC）に関する調査レポート

https://www.openid.or.jp/news/oidfj_kycwg_report_20200123.pdf

 本⼈確認には継続した確認が必要でありコストもかかる
Ongoing（利⽤中）のアカウントID利⽤時には、
Authentication（当⼈確認:認証）が必要
 Authentication︓ID情報との紐付けを確認する
例︓ID/パスワード・指紋等⽣体情報・ICカード等を利⽤

6LangEdge,Inc.

電子認証利用の流れ
本人確認（身元確認）

どのような情報で本人確認をしたかでIDの保証レベルが異なる（IAL）。
例）

登録（本人である）

高：対面で公的写真付きIDを確認
低：メール到達により実在を確認

認証（当人確認）

どのような情報で当人確認をしたかで認証の保証レベルが異なる（AAL）。
例）

認可（アクセス権確認）
リソース/サービス利用
削除（利用終了）

高：２要素認証により確認
低：４桁固定のPINだけで確認必要機能を全て１システムで提供することも可能だが、⼤変なので機能毎に分けたID連携をするようになってきた。

7

LangEdge,Inc.

認証画面と認可画面の例
認証画面

カレンダーサービス Jorte Cloud が、Googleカレンダー に対するアクセスの認可を求める場合の画面の例。

認可画面

LangEdge,Inc.

8

ID連携 （ID Federation） と SSO （Single Sign On）
ID連携︓異なるドメイン間にてIDを連携する仕組み。
SSO︓異なるドメイン間にて認証セッションを継続する仕組み。
主なSSOの⽅式＞

1. ケルベロス認証⽅式（同⼀ドメインSSO内向け）

 サーバ・クライアント間で認証処理を⾏う
例︓ActiveDirectory（Windowsドメイン内でのリソースアクセス等）

2. リバースプロキシ⽅式（同⼀ドメインSSO内向け）


全てのサーバ接続をリバースプロキシ経由として認証処理を⾏う

3. エージェント⽅式（同⼀ドメイン内SSO向け）


各サーバに常駐するエージェントソフトが認証処理を⾏う

本資料の対象4. フェデレーション⽅式（複数ドメイン間を跨いだSSO向け）
 IDプロバイダ（IdP）へリダイレクト（連携）して認証を⾏う FacebookやTwitter等のクラウドサービスでの利⽤が多い
 仕様が標準化されており相互運⽤性が⾼い（クラウドで普及）
例︓SAML/OAuth2.0+OpenID Connect

9LangEdge,Inc.

フェデレーション方式の構成と利用手順
IDプロバイダ（OP/IdP） OP: OpenID Provider

利用までの手順① Subscriber→RP : アクセス
② RP→(Subscriber)→IdP : 認証要求
③ Suscriber→IdP : 認証（当人確認）④ IdP→(Subscriver)→RP : 認証結果
⑤ IdP→RP : 属性（必要なら）⑥ Subsriber→RP : サービス利用※ 事前に本人確認と登録済み

IdP: Id Provider （SAML）

（属性）
認証結果

[ ブラウザ ]登録利用者（Subscriber）

RP: Relying Party
SP: Service Provider （SAML）

サービス（RP/SP）

10

LangEdge,Inc.

フェデレーション方式の利用シーケンス[ ブラウザ ]登録利用者[ Webサーバ ]RPサービス[ 認証サーバ ]IDプロバイダ（IdP）
RPサービスへアクセス
IdPへリダイレクトされる

認証処理
認証結果と共にRPへリダイレクト
認証結果の確認（属性の取得）RPサービスの利用

LangEdge,Inc.

11

OECD（経済協力開発機構） ８原則 （参考）1980年に定められた個⼈情報保護の基本原則
１．目的明確化の原則（Purpose Specification Principle）
 個人データの収集目的を明確にし、データ利用は収集目的に合致するべき。
 個人情報保護法：第１５条（利用目的の特定）

２．利用制限の原則（Use Limitation Principle）
 データ主体（個人情報の持ち主）の同意がある場合や法律の規定による場合を除いては、収集したデータを目的以外に利用してはいけない。
 個人情報保護法：第１６条（利用目的による制限）、第２３条（第三者提供の制限）

３．収集制限の原則（Collection Limitation Principle）
 個人データは、適法・公正な手段により、かつ情報主体に通知または同意を得て収集されるべき。
 個人情報保護法の対応：第１７条（適正な取得）

４．データ内容の原則（Data Quality Principle）
 収集する個人データは、利用目的に沿ったもので、かつ、最新・正確・完全であるべき。
 個人情報保護法：第１９条（データ内容の正確性の確保）

５．安全保護の原則（Security Safeguards Principle）
 合理的安全保護措置により、紛失・破壊・使用・修正・開示等から保護すべき。
 個人情報保護法：第２０条（安全管理措置）、第２１条（従業者の監督）、第２２条（委託先の監督）

６．公開の原則（Openness Principle）
 個人データ収集の実施方針等を公開し、データの存在、利用目的、管理者等を明示するべき。
 個人情報保護法：第１８条（取得に際しての利用目的の通知等）、第２４条（保有個人データに関する事項の公表等）

７．個人参加の原則（Individual Participation Principle）
 自己(データ主体)に関するデータの所在及び内容を確認させ、または異議申立を保証するべき。
 個人情報保護法：第２５条（開示）、第２６条（訂正等）、第２７条（利用停止等）

８．責任の原則（Accountability Principle）
 個人データの管理者は諸原則実施の責任を有する。
 個人情報保護法：第３１条（苦情処理）

LangEdge,Inc.

12

アイデンティティ ７原則 （参考）2005年に元MSのキム・キャメロン⽒が作成した基本原則、以後マイクロソフトのアイデンティティ基本原則となる
原則１．ユーザーによる制御と同意
 アイデンティティ・システムは、ユーザーの同意がなければユーザーを識別する情報を開示すべきではない。

原則２．限定された用途で最低限の公開
 最も安定し、長期にわたって使用できるソリューションとは、開示するアイデンティティ情報を最小限にし、情報へのアクセスを適切に制限するソリューションである。

原則３．正当な関係者のみへの情報開示 アイデンティティ・システムは、特定の状況において識別情報を必要とし、かつ入手できる正当な権利を持つ関係者のみに対して情報を開示するように設計されなければならない。

原則４．方向付けられたアイデンティティ
 アイデンティティ・システムは、公に使用する「全方位的」な識別子とプライベートで使用する「特定の方向性」を持った識別子の両方をサポートしなければならない。このことにより公共性を維持しながら不必要に関連付けの公開を防止できる。

原則５．複数のアイデンティティ・プロバイダと技術の相互運用性
 アイデンティティ・システムは、複数のアイデンティティ・プロバイダによって実行される複数のアイデンティティ技術の相互運用性を保持しなければならない。

原則６．人間の統合
 アイデンティティ・システムは、利用者たるユーザーを分散システムの1つのコンポーネントとして定義しなければならない。
明確なマンマシン・インターフェイスを策定してユーザーを分散システムに統合し、アイデンティティを保護しなければならない。

原則７．シンプルで一貫性のあるユーザー・エクスペリエンス
 アイデンティティ・システムは、さまざまな状況下でのアイデンティティ・コンテキストの分離を可能にしつつも、一貫性のあるユーザーとテクノロジのインターフェイスを提供しなければならない。

LangEdge,Inc.

13

１．認証入門：ID・アイデンティティ・認証
２．認証基本：NIST SP 800-63-3
３．認証利用：OAuth 2.0・OpenID Connect
４．認証応用：PKCE・FIDO2

14

LangEdge,Inc.

NIST SP 800-63-3 : Digital Identity Guidelines
2017年6⽉にNIST（⽶国標準技術研究所）からFinal版が公開。
⽶国政府機関向けのデジタルID実装ガイドライン。
https://pages.nist.gov/800-63-3/

SP 800-63-3 Digital Identity Guidelines「デジタルIDガイドライン」 全体の概要

SP 800-63A Enrollment and Identity Proofing「登録と身元情報の検証」 本人確認のガイドライン
IAL（Identity Assurance Level）の定義

SP 800-63B Authentication and Lifecycle Management「認証とライフサイクル管理」 当人確認のガイドライン
AAL（Authenticator Assurance Level）の定義

SP 800-63C Federation and Assertions「連携とアサーション」 連携時の認証/認可/属性情報
FAL（Federation Assurance Level）の定義

日本でも 「行政手続におけるオンラインによる本人確認の手法に関するガイドライン」 等が参照。
https://cio.go.jp/sites/default/files/uploads/documents/hyoujun_guideline_honninkakunin_20190225.pdf

LangEdge,Inc.

15

保証レベル （Assurance Level）
SP 800-63-2 では１種類のLoAで４レベルを規定。
 各項⽬のレベルを合わせる必要があると⾔う問題があった。
LoA︓Level of Assurance

SP 800-63-3 では３種類のALで各３レベルを規定。

 ⽤途に合わせて各項⽬のレベルの組み合わせが可能になった。
A) 本⼈確認保証レベル︓IAL（Identity Assurance Level）B) 当⼈認証保証レベル︓AAL（Authenticator Assurance Level）
C) 連携情報保証レベル︓FAL（Federation Assurance Level）
 レベル１は、最低限（minimum）の要件。
 レベルを合わせる必要は無く、匿名（IAL1）でAAL2でも良い。
 デジタルIDシステムを設計するなら特にIALとAALは重要。
 FALは現実的にはレベル１かせいぜいレベル２⽌まり。
 レベル３は⽶国の機密情報へのアクセスレベル（⾮現実的）。

LangEdge,Inc.

16

IAL （Identity Assurance Level）
ユーザが申請者（Applicant）として、新規登録（SignUp）する際に、CSP（Credential Service Provider）が⾏う、本⼈確認（Identity
Proofing）の厳密さや強度、を⽰す。

IAL.1 本人確認不要、自己申告での登録でよい。
サービス内容により識別に用いられる属性を
IAL.2
リモートまたは対面で確認する必要あり。
識別に用いられる属性を対面で確認する必要
IAL.3 があり、確認書類の検証担当者は有資格者の必要あり。

LangEdge,Inc.

17

AAL （Authenticator Assurance Level）
登録済みユーザ（Claimant）が、ログインする際の認証プロセス（単要素認証or多要素認証、認証⼿段）の強度、を⽰す。
Claimant は認証されることで加⼊ユーザ（Subscriber）となる。

AAL.1 単要素認証でよい。
2要素認証が必要、2要素目の認証手段はソフ
AAL.2
トウェアベースのものでよい。
2要素認証が必要、かつ2要素目の認証手段
AAL.3 はハードウェアを用いたもの（ハードウェアトー
クン等）が必要。

LangEdge,Inc.

18

認証要素と段階
認証要素の種類（3種類のみ）︓

知識 当人しか知り得ない情報（PIN番号・パスフレーズ 等）
所有 当人しか所有していない物に依存（ICカード・トークン 等）
生体 当人の生体としての情報（指紋・光彩・顔認識 等）
２要素認証︓
3つの要素の種類のうちの2つの要素による認証。
例︓知識＋所有 や 知識＋⽣体 の組み合わせが多い。
２段階認証︓
認証プロセスを２段階に分けて⾏う。
例︓最初にパスワード認証を⾏い、次に秘密の質問を⾏う。
※ NIST SP 800-63B では2段階認証の価値を認めていない。
※ NIST SP 800-63B ではパスフレーズの定期的変更は⾮推奨。
→ ただしパスフレーズが危殆化した場合には変更を強制する。

19

LangEdge,Inc.

Authenticator（認証コード）の種類
No

名称

要素種別

鍵所持証明

ハードウェア1Memorized Secret
記憶シークレット （パスワード等）

知識

認められない認められない2

Look-up Secret
ルックアップシークレット （乱数表等）

所有

認められない認められない3

Out of Band Device
経路外デバイス （SMS等、メール/VoIPは不可）所有認められない認められない4

SF（Single Factor） OTP Device
単一要素OTPデバイス（アプリ）

所有認められない△内容による

5

MF（Multi Factor） OTP Device
多要素OTPデバイス（アプリ）

所有+知識/生体認められない△内容による6

SF Cryptographic Software
単一要素暗号ソフトウェア （クライアント証明書等）

所有〇認められる

認められない7

SF Cryptographic Device
単一要素暗号デバイス （USBドングル等）

所有〇認められる〇認められる

8

MF Cryptographic Software
多要素暗号ソフトウェア

所有+知識/生体〇認められる

認められない9

MF Cryptographic Device
多要素暗号デバイス （FIDO/ICカード等）

所有+知識/生体〇認められる〇認められる

20

LangEdge,Inc.

FAL （Federation Assurance Level）
IDトークンやSAML Assertion等、Assertion（認証情報・属性・
認可情報）のフォーマットやデータやり取りの仕⽅の強度、を⽰す。

Assertion（RPに送るIdPでの認証結果データ）へのFAL.1
署名が必要。
レベル１に加えて、対象RPのみが復号可能な
FAL.2
暗号化が必要。つまり署名＋暗号化が必要。
レベル２に加えて、Holder-of-Key Assertionの利用（ユーザごとの鍵とIdPが発行したAssertionを

FAL.3 紐づけてRPに送り、RPはユーザがそのAssertionに紐づいた鍵を持っているか（ユーザの正当性）を確認）

が必要。

21

LangEdge,Inc.

SP 800-63-3 デジタルIDモデル図
Enrollment and Identity Proofing
本人確認と登録

Authenticated Session
認証されたセッション
RP
証明書利用者

becomes
認定

Subscriber
加入者

becomes
認定
Claimant
認証要求者

Applicant
申請者
Authenticator
Enrollment/
Issuance
認証コードの
登録/発行

Enrollment and
Identity Proofing
登録と身元情報の検証「bocomes」の訳語が「認定」？
昇格とかの方が良い気もする。

Authentication
Assertion
認証
アサーション

Authenticate
認証
Validate Authenticator/Credential Binding
認証コード/認証情報の検証

CSP
認証情報
サービスプロバイダ

Attributes
属性

Verifier
検証者

Digital Authentication
デジタル認証（当人確認）

22

LangEdge,Inc.

デジタルIDモデル図（改）Step 1 : 登録フェーズ

Step 2 : 利用フェーズ

Enrollment and Identity Proofing

Digital Authentication

本人確認と登録

デジタル認証（当人確認）
利用者

認証
コード

Authenticator
Enrollment/
Issuance
認証コードの登録/発行

注：SP 800-63-3 の図とは異なります。

becomes
昇格
Applicant
申請者

becomes
昇格
Claimant
認証要求者

Enrollment and
Identity Proofing
登録と身元情報の検証（本人確認）

Subscriber
加入者

認証
コード

AuthenticatedSession
認証された
セッション

クライアント
RP
証明書利用者

Authenticate
認証（当人確認）

Authentication
Assertion
認証
アサーション

Validate Authenticator/Credential Binding
認証コード/認証情報の検証
CSP (IdP)
認証情報
サービスプロバイダ

認証
サービス

Attributes
属性

Verifier
検証者

23

LangEdge,Inc.

デジタル署名モデル図（参考）Step 1 : 登録フェーズ

Step 2 : 利用フェーズ

Enrollment and Identity Proofing

Digital Signature

本人確認と登録

デジタル署名（当人保証）証明書
秘密鍵

Certificate
Enrollment/
Issuance
証明書の
登録/発行

becomes
昇格
Applicant
申請者

利用者

Signer
署名者

Sign
署名
証明書
秘密鍵

書
類

SubmitApplication Form
電子申請

電子申請
サービス等
書
類
RP
証明書利用者

Enrollment and
Identity Proofing
登録と身元情報の検証（本人確認）

CSP (CA)
認証情報
サービスプロバイダ

Certificate
Information
証明書情報
Certificate Trust/Revoke Verification
証明書信頼性/失効情報の検証

信頼済み
第三者機関
TTP
(Trusted Third Party)※ Step1の登録フェーズはデジタルIDモデルとほぼ同じ内容。

Verifier
検証者

LangEdge,Inc.

24

１．認証入門：ID・アイデンティティ・認証
２．認証基本：NIST SP 800-63-3
３．認証利用：OAuth 2.0・OpenID Connect
４．認証応用：PKCE・FIDO2

LangEdge,Inc.

25

SAML と OAuth2.0
SAML（Security Assertion Markup Language）

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

策定︓OASIS v2.0 を2005年発⾏
メッセージ送受信︓SOAP/HTTP
通信⾔語︓XMLベース
主な実装︓Shibboleth（学術系で広く利⽤、⽇本では学認が利⽤）※ 「SAML is dead!」 と⾔われながらまだまだ使われている。

OAuth 2.0 Authorization Framework（RFC 6749）
https://tools.ietf.org/html/rfc6749
https://openid-foundation-japan.github.io/rfc6749.ja.html [和訳]策定︓IETF（インターネットコミュニティ）2012年発⾏
メッセージ送受信︓HTTPS（RESTful）
通信⾔語︓JSONベース
利⽤︓実装のハードルが低くクラウドサービスで広く利⽤されている

LangEdge,Inc.

26

OAuth 2.0 登場人物（ロール）OAuth 2.0 のロールは以下4種類：

1. Resource Owner （またはエンドユーザ） エンティティが人間の場合にはエンドユーザである。

2. Resource Server （リソースサーバ）
 アクセストークンを受理し、保護されたリソースへのアクセスのレスポンスを返す。クライアントと同じ場合も多い。

3. Client （クライアント） リソースオーナーの認可を受けて、保護されたリソースへのアクセスを行うアプリケーション（Webサービス等）。

4. Authorization Server （認可サーバ） リソースオーナーの認可を確認してアクセストークンを発行するサーバ。

27

LangEdge,Inc.

OAuth 2.0 登場人物（ロール）の関係(A) AuthZ Request(B) AuthZ Grant

リソースオーナー（エンドユーザ）(C) AuthZ Grant
クライアント（Webサービス）(D) Access Token

認可サーバ(E) Access Token(F) Protected Resorce

リソースサーバ

AuthZ Grant： リソースにアクセスするために使用するオーナーの認可を示すクレデンシャル。
Access Token： リソースにアクセスする為に認可サーバが発行するチケット（トークン）。

LangEdge,Inc.

28

OAuth 2.0 フロー種別
OAuth 2.0 の主なフローは以下4種類：

1. Authorization Code Flow （基本：Webサービスでの推奨フロー） 認可リクエスト時：response_type=code
 アクセストークンリクエスト時：grant_type=authorization_code
 認証トークンからWebサービスが直接アクセストークンを取得

2. Implicit Flow （簡略化されたフローで時々使われている）
 認可リクエスト時：response_type=token
 認可時に直接アクセストークンを取得するのでgrant_typeは定義されていない
 クライアントアプリがアクセストークンを取得するリスクがある

3. Resource Owner Password Credentials Flow （説明省略）
 アクセストークンリクエスト時：grant_type=password
 アクセストークンリクエスト時に認証情報を付けて要求する
 オーナー保有デバイス等からアクセストークンリクエストして直接トークンを取得

4. Client Credentials Flow （説明省略）
 アクセストークンリクエスト時： grant_type=client_credentials
 オーナーが信頼関係にありユーザ認証しなくても良い時のフロー

Webサービスでは Authorization Code Flow を使うべき。
参考 https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

29

LangEdge,Inc.

Authorization Code Flow のシーケンス
エンドユーザクライアント [認可リクエスト]
request service

redirect to AuthZ server

認証処理

認可サーバ

response_type=code
client_id=AAA
redirect_uri=https:BBB
scope=CCC
state=DDD

リソースサーバ

AuthZ code の利用は1回のみなのでワンタイム
か期限を短くする。

end user AuthN
認証（当人確認）

redirect to service (AuthZ code)(AuthZ code)[認可レスポンス]
code=EEE
state=DDD[アクセストークンレスポンス]
access_token: FFF
token_type: Bearer
expires_in: 3600
refresh_token: GGG
scope: CCC…

request access token (AuthZ code)(access token)[アクセストークンリクエスト]
grant_type=authorization_code
code=EEE
redirect_uri=https:BBB
client_id=AAA
認証済みサービス（クライアント）で無ければclient_idの指定と検証は必須

request resource (access token)
ヘッダにBearerトークン
Bearer FFF(resource)

request validation (access token)

30

LangEdge,Inc.

Implicit Flow のシーケンス
エンドユーザクライアント [認可リクエスト]
request service

redirect to AuthZ server

認証処理

認可サーバ

response_type=token
client_id=AAA
redirect_uri=https:BBB
scope=CCC
state=DDD

リソースサーバ

認可サーバがエンドユーザを経由し直接アクセストークンをサービスに返す。

end user AuthN
認証（当人確認）

redirect to service (access token)(access token)[アクセストークンレスポンス]
access_token: FFF
token_type: Bearer
expires_in: 3600
scope: CCC
state: DDD…
refresh_token の利用は不可

request resource (access token)
ヘッダにBearerトークン
Bearer FFF(resource)

request validation (access token)

LangEdge,Inc.

31

OAuth 2.0 のパラメーター
1. scope （アクセス権限の範囲指定）
 アクセスする範囲を示すパラメーターで省略時はデフォルト
値を使うかエラーとすべき。エンドユーザに範囲を提示して確認することが必要。独自に設計する必要がある。
例：’Mail.Read’

2. state （なりすまし対策）
 CSRF（クロスサイトリクエストフォージェリ）対策として利用
する、サービス（クライアント）が指定する乱数パラメーター。
 必須パラメーターではないが指定すべき。

3. refresh_token （アクセストークンの更新） アクセストークン有効期間内に同じ認可グラントに対して、
新しいアクセストークンを取得する為の属性（Refresh Token Flow） 。
 事実上アクセストークンの有効期間を延長することが可能。

32

LangEdge,Inc.

OAuth 2.0 ＋ OpenID Connect
OAuth は 「Authorization Framework （認可フレームワーク）」であり認証フレームワークを含まない。この為に OAuth だけで認証も行った場合（OAuth認証と呼ばれる：後述）にセキュリティリスクを生じる可能性がある。なおSAMLは認証認可に対応している。
OpenID Connect は、OAuth をベースに 「アイデンティティ層」
を拡張した、 2014年発行の OpenID 最新仕様。OAuth 2.0 をベースに新規策定された為 OpenID 1.0/2.0 との互換性は無い。
策定：オープンIDファウンデーションが2014年に1.0を発行
https://openid.net/connect/
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html [和訳]
OAuth 2.0

認可層

OpenID Connect 1.0

アイデンティティ層

FIDO2 （後述）

認証層

LangEdge,Inc.

33

OpenID Connect

OAuth 2.0仕様
JSON 仕様34

LangEdge,Inc.

Authorization Code Flow （+ OpenID Connect）
RP（クライアント）

エンドユーザOP（認可サーバ）

request service
redirect to OP server

認証処理
認可処理

end user AuthN
end user AuthZ
redirect to RP (AuthZ code)(AuthZ code)[認可レスポンス]
code=EEE
state=DDD[アクセストークンレスポンス]
access_token: FFF
token_type: Bearer
expires_in: 3600
refresh_token: GGG
id_token: HHH…
クライアント（RP）はid_tokenを検証する必要がある。

request access token (AuthZ code)

UserInfo[認可リクエスト]
scope=openid profile …
response_type=code
client_id=AAA
redirect_uri=https:BBB
state=DDD
nonce=EEE
nonceはid_tokenに含まれる[アクセストークンリクエスト]
grant_type=authorization_code
code=EEE
redirect_uri=https:BBB
client_id=AAA(access token / id token)
userinfo request (access token)
userinfo response (user info)[ユーザ情報レスポンス]
sub=JJJ （ユーザ識別子）
name=alice…

35

LangEdge,Inc.

Implicit Flow （+ OpenID Connect）
RP（クライアント）

エンドユーザOP（認可サーバ）

request service
redirect to OP server

認証処理
認可処理

end user AuthN
end user AuthZ

UserInfo[認可リクエスト]
scope=openid profile …
response_type=id_token token
client_id=AAA
redirect_uri=https:BBB
state=DDD
nonce=EEE
nonceはid_tokenに含まれる

redirect to RP (access token / id token)(access token / id token)[アクセストークンレスポンス]
access_token: FFF
token_type: Bearer
expires_in: 3600
クライアント（RP）はid_tokenを
refresh_token: GGG
検証する必要がある。
id_token: HHH…

userinfo request (access token)

userinfo response (user info)[ユーザ情報レスポンス]
sub=JJJ （ユーザ識別子）
name=alice…

36

LangEdge,Inc.

IDトークン付きアクセストークンレスポンス例
OPから取得するアクセストークンレスポンスはJSON形式で返される。
{

OAuth 2.0

OpenID Connect の、
id_token部はJWT形式にパッケージされて返される。

"access_token": "SlAV32hkKG","token_type": "Bearer","refresh_token": "8xLOxBtZp8","expires_in": 3600,"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"}

37

LangEdge,Inc.

JWT （Json Web Token）
JWT はURL引数のトークンに使えるJSONベース仕様で RFC 7519 定義。

※ 署名の JWS（Json Web Signature）、暗号化の JWE（Json Web Encryption）をベースとしている。

Header/Payload/Cryptoの 3パートをBase64化して “.” で接続する。
Part1. Header Input ︓ 署名アルゴリズム等の属性をJSON記述
Part2. Payload Input ︓ 署名対象のJSON記述
Part3. Crypto Output ︓ 署名値そのもの（バイナリ値）
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLA0KICJleHAi
OjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV
lfQ.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

JWTのサンプル
ヘッダ（Header）部 Base64展開

署名対象（Payload）部 Base64展開{{“typ”: “JWT”,“alg”: “HS256”}“alg”:”HS256” = HMAC-SHA256“alg”:”RS256” = RSA-SHA256“iss”: ”oe”,“exp”: 1300819380,“http://example.com/is_root”: true}

LangEdge,Inc.

38

ID Token （認証情報）
ID Token は発⾏元であるOPの署名が付与されているJWTデータ。
JWS署名をOP公開鍵で検証することでOP発⾏を保証している。
ID Token のJWTペイロード部のサンプルを以下に⽰す。
{"iss": "https://server.example.com", Issuer (発行元:OP)
Subject ID (ユーザ識別子)"sub": "24400320",
Audience (RPのclient_id)"aud": "s6BhdRkqt3",
Expire (有効期限)"exp": 1311281970,
発行時刻"iat": 1311280970,
認証時刻"auth_time": 1311280969,
セッションとid_tokenを紐付"nonce": "n-0S6_WzA2Mj",}
Issuer: OPのこと（IdP︓IDプロバイダ）
Audience : RPのこと（クライアント︓サービス等）
Subject: エンドユーザのこと（ユーザID︓識別⼦）

nonce はリプレイアタック対策
必須では無いが使いましょう

ID Token : OPがRPの為にエンドユーザ認証情報を提供（⾮改ざんと発⾏元を保証）

LangEdge,Inc.

39

属性情報 と UserInfo エンドポイント
認可リクエスト時の scope で取得する属性情報群（Claims）を指定。
認証済みのクライアントに対して属性情報群（Claims）を返す。
OpenID Connect では属性取得の UserInfo 仕様も追加された。
属性情報を取得する⽅法は以下の2種類︓

1. ID Token に含めて返す。
2. UserInfo エンドポイントのリクエストに返す。
UserInfo エンドポイント︓A) OP/リソースサーバが提供するRESTfulなAPI。
B) RPは取得したアクセストークンを⽤いて属性情報を取得。
C) 認可リクエスト時に指定されたscopeの属性情報を返す。
指定例︓scope=openid profile email phoneD) 取得した属性情報は通常JSON形式で返される。

40

LangEdge,Inc.

標準定義の scope と Claims
scope

Claim （返される属性情報）

属性概要

---

sub

Subject - Issuer における End-User の識別子

profilename

End-User の表示用フルネーム. 肩書きや称号 (suffix) 等が含まれることもある.

family_name

End-User の姓 (surname / last name).

given_name

End-User の名 (given name / first name).

middle_name

End-User の middle name.

nickname

End-User のニックネーム. これは given_name と同じこともあれば異なることもある.

preferred_username

janedoe や j.doe といった, End-User の簡略名.

profileEnd-User のプロフィールページの URL.

pictureEnd-User のプロフィール画像の URL.

websiteEnd-User の Web ページやブログの URL.

gender

End-User の性別. 本仕様では female, male を定義する.

birthdate

End-User の誕生日. ISO 8601:2004 [ISO8601-2004] YYYY-MM-DD 形式で表現される.

zoneinfo

End-User のタイムゾーンを示す zoneinfo [zoneinfo] に登録された文字列.

localeEnd-User の locale. BCP47 [RFC5646] 言語タグ表現.

updated_at

End-User に関する情報の最終更新日時.

email

End-User の Email アドレス. RFC 5322 [RFC5322] のシンタックスに従うこと.

email_verified

End-User の Email アドレスが検証済であれば true, さもなければ false.

phone_number

End-User の電話番号. この Claim のフォーマットとしては E.164 [E.164] を推奨する.

phone_number_verified

End-User の電話番号が検証済であれば ture, さもなければ false.

address

End-User の郵送先住所. JSON Object で表記.

email

phone

address※ 独自の scope と Claim の組み合わせも独自に定義が可能。

※ OAuth 2.0 の scope パラメータの指定は全て独自定義だった。

41

LangEdge,Inc.

PPID と sub Claim （ユーザ識別子）
PPID : Pairwise Pseudonymous Identifier （対の仮名識別⼦）※ PPIDの対語は、 Public Identifier（共通識別⼦）

 Entity（ユーザ）識別⼦として、あるRP（サービス）に対してのみ提供するID。
 他のRPに対して、同じPPIDをそのEntityと関連付けて提供してはいけない。
 PPID採⽤︓Facebook/LINE、共通ID採⽤︓Google/Twitter/Fahoo※ 名寄せ対策（と⾔っても実際にはセキュリティ向上の為に導⼊されている）

sub : Subject ID（ユーザ識別⼦）

メールアドレスが乗っ取られた
場合の影響が大きい 共通IDとして sub = email を利⽤することは、ID連携では推奨されない。
 パーマメントな（耐久性がある）ID（ユーザ識別⼦）の利⽤をする。
 sub Claim は⼝頭での名寄せの可能性があり、ユーザには提⽰しない⽅が安全。

OpenID Connect でのPPIDの⽣成仕様︓
 Subject Identifier 値が, OpenID Provider 以外の Party にとって, 可逆であってはならない (MUST NOT) 異なる Sector Identifier 値は, 異なる Subject Identifier 値にならなければならない (MUST) 同じ⼊⼒に対して必ず同じ結果となる決定的アルゴリズムでなければならない (MUST)
計算例︓

クライアントのURLを利用することが多い

sub = SHA-256 ( sector_identifier || local_account_id || salt )sub = AES-128 ( sector_identifier || local_account_id || salt )42

LangEdge,Inc.

認証HTTPS通信のパラメータ指定
認証HTTPS通信での認証パラメータの渡し⽅は3種類ある︓
1. HTTPSのPOSTメソッドでFORM形式渡し（リダイレクト不可）
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
tmp_token=aaa

POSTメソッドはリダイレクト時にBODY部が失われる。
サーバへのパラメーター指定時はJSON形式
では無いことが多い。JSONの場合もある。

2. HTTPSのGETメソッドでURL引数渡し（リダイレクト可）
https://server.example.com/token?tmp_token=aaa

3. HTTPSのGETメソッドのURLフラグメント部渡し（リダイレクト時）
https://server.example.com/token#tmp_token=aaa

通常フラグメント部はid名への移動等に利用

GETメソッドのURLフラグメント部はリダイレクトによりブラウザ経由するとサーバには渡らない。フラグメント部の処理はブラウザが⾏う為で、その点URL引数と異なる。
リダイレクト時のURLフラグメント部にパラメーター指定することで、⼀旦ブラウザ上のJavaScriptで取得して確認やURL引数等へ変換する必要がある。
※ OAuth 2.0 Multiple Response Type Encoding Practices（Implicit Flow Response 等）

LangEdge,Inc.

43

１．認証入門：ID・アイデンティティ・認証
２．認証基本：NIST SP 800-63-3
３．認証利用：OAuth 2.0・OpenID Connect
４．認証応用：PKCE・FIDO2

LangEdge,Inc.

44

Access Token （Bearer Token） の問題
Access Token を Bearer（持参人） Token 仕様でサーバに提示。
利用時HTTP通信でAuhtorizationヘッダにBearerを追加する：

Authorization: Bearer <access_token>
リソースの利用認可としては 「これだけが条件」 となる。
誰かが不正に Access Token を入手して提示しても分からない。

Token置換攻撃（OAuth認証）： Implicit Flow
不正クライアントが OAuth 2.0 の Implict Flow にて、不正に入手した
Access Token を使って他RPへ なりすまし攻撃 することが出来てしまう。
 OpenID Connect を使う（提供先RPを確認）ことも対策の１つ。

認可コード横取り攻撃： Authorization Code Flow
クライアントがモバイルアプリ（ネイティブアプリ）の時にリダイレクトを悪用して認可コードを取得して Access Token の横取り が出来てしまう。
 モバイルアプリの認証では、内蔵ブラウザで認証処理を行い、カスタムURL
スキーム（アプリ用の起動スキーム）にリダイレクトすることで連携をしている。

45

LangEdge,Inc.

認可コード横取り攻撃 （Authorization Code Interception Attack）
END Device （スマホ等）
正当な（legitimate）
OAuth 2.0 アプリ
myapp:(6) Access Token
悪意の（Malicious）
アプリ badapp:(5) AuthZ Grant(4) AuthZ code

(1) AuthZ request

カスタムURLスキームを上書き
例 myapp:/token?code=AAA

AuthZ
Server
認可サーバ(3) AuthZ code
OS/ブラウザ(2) AuthZ request

悪意のアプリはカスタムURLスキームを悪用して、認可サーバから取得した AuthZ code を横取りし、認可サーバに対し Access Token を要求する攻撃。

46

LangEdge,Inc.

OAuth PKCE （ピクシー：認可コード横取り攻撃対策）
RFC 7636 : Proof Key for Code Exchange by OAuth Public Clients
https://tools.ietf.org/html/rfc7636
SHA256

code_verifier : クライアントで作成するランダム値
code_challenge_method : チャレンジ作成方法（例：S256）
code_challenge = code_challenge_method ( code_verifier )Client
スマホアプリ
code_verifier 生成
code_challenge 計算(A) AuthZ request+ code_challenge+ code_challenge_method(B) AuthZ code

code_verifier を渡す

AuthZ Server
認可サーバ
AuthZ
endpoint

code_challenge とcode_challenge_method
の保存

Token
endpoint

code_verifier から再計算
code_challenge と比較(C) access token request+ AuthZ code + code_verifier(D) access token※ PKCEは、もともとモバイルアプリ向け仕様だったが、最近では全利用形態での利用が推奨されて来ている。

LangEdge,Inc.

47

Confidential Client と Public Client
クライアント認証に関するクライアントの分類：

Confidential Client ： シークレット情報の漏えいを心配する必要がないクライアント。
 クライアントIDとシークレット情報でクライアント認証できる。
例：Webアプリ（Webサービス）

Public Client ： シークレット情報の漏えいする可能性があるクライアント。
 シークレット情報によるクライアント認証にはリスクがある。
 PKCEの利用が推奨される。
例：ネイティブアプリ（モバイルアプリ）、JavaScriptアプリ※ redirect_uri パラメータ ：クライアントから認可サーバに送られる redirect_uri も、クライア
ント登録時に登録されたものと同一であることを確認すべき。

48

LangEdge,Inc.

FIDO （Fast IDentity Online）
FIDO Alliance が策定する認証標準仕様
https://fidoalliance.org/

メンバー︓Google, Microsoft, Alibaba 等、200社近くが加盟「FIDO is an ʻauthenticationʼ standard, not an ʻidentityʼ standard.」

FIDOは認証標準であってアイデンティティ標準では無い︕

FIDOは状況に応じて認証強度とUXを選択できる認証処理の標準。
※ OpenID Connect は認証処理の詳細に関しては仕様対象外。

IdP（認可サーバ）

RP（クライアント）

エンドユーザrequest service
USB Authenticator

FIDO

redirect to OP server

認証処理
認可処理

エンドユーザと認可サーバ間の認証フロー部

end user AuthN
end user AuthZ
redirect to RP (access token)(access token)

49

LangEdge,Inc.

FIDO と FIDO2
FIDO （FIDO1）: Universal Authentication Framework
 パスワードレス認証 仕様: Universal Second Factor
 ２要素認証 仕様

生体情報等によりパスワードレス認証を実現するアプリ（スマホ組込み）

パスワード認証に加えて別要素で認証する機器（ハード）の仕様※ FIDO2のCTAP1仕様に移行※ 追加認証仕様の為他仕様とは異なる

FIDO2

移行/統合

連携動作

上位互換

: Client To Authenticator Protocol: Web Authentication
 認証器 通信仕様 （CTAP2）  W3C勧告 Web認証仕様
認証器との通信プロトコル仕様
外付けの認証器をFIDO2対応にする為の仕様 （多要素可）

https://www.w3.org/TR/webauthn/

公開鍵暗号認証のAPI
An API for accessing Public Key Credentials※ JavaScript/AndroidのAPIと通信プロトコル※ 仕様 https://fidoalliance.org/specifications/download/

50

LangEdge,Inc.

FIDO2 シーケンス
CTAP
エンドユーザ

認証器

WebAuthn

クライアント（ブラウザJS等）

認証サーバ（RP）

Request Regist

登録

UV: User Verification (opt)
generate key pair(challenge / policy …)
Attestation Response(sign / meta / public-key …)(challenge / policy …)

Attestation Response(sign / meta / public-key …)

アテステーション秘密鍵で署名

登録完了
Request AuthN (userid)

認証

UV: User Verification
sign to challenge by private-key(challenge / user-info …)
AuthN Response(sign …)

(challenge / user-info …)

AuthN Response(sign …)

認証用秘密鍵で署名

認証完了

ローカル認証

リモート認証LangEdge,Inc.

51

WebAuthn: 公開鍵暗号方式の認証
登録︓navigator.credentials.create()
1. 認証器（Authenticator）内で公開鍵ペアを⽣成する。
 ⽣成する公開鍵ペアは認証サーバ（RP）毎に異なる
 秘密鍵は認証器内で保管（認証器の外には出さない）

2. 認証サーバへアテステーションと公開鍵を送り公開鍵を登録する。
 アテステーション（Attestation）︓認証器の発⾏ベンダー署名付き情報

認証︓navigator.credentials.get()a. 認証サーバ（RP）はチャレンジ情報をクライアントに送る。
b. 認証器の機能で認証を⾏い、利⽤者を認証する。
 利⽤する認証器はポリシーで指定・選択が可能

c. 認証完了したら認証器はチャンレンジ情報に署名して返す。
d. 認証サーバは登録済み公開鍵で検証して認証完了を確認する。
※ ⽣体等の認証情報はローカルで利⽤されるだけなのでサーバに漏えいしない。
※ 認証サーバ・クライアント間の通信プロトコルは標準化されているので認証⽅法に関係なく共通化される（認証器を選べる）。
※ 利⽤者は公開鍵ペアに関して知る必要は無い（知らない）。

52

LangEdge,Inc.

OpenID Connect CIBA （シーバ） Flow
CIBA : Client Initiated Backchannel Authentication

https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html

OIDCでドラフトを2018年に公開、クライアント開始バックチャンネル認証のフロー。
新しいロールとして認証デバイスを追加

認証デバイス

エンドユーザrequest service

認証処理

IdP（認可サーバ）

RP（クライアント）
CIBA request
User interactions
CIBA response(access token, etc..)

CIBA Response の３つのモード︓⾮同期連携の為クライアントは認証終了を待つ
Poll（反復問合せ）, Ping（通知後取得）, Push（直接送信） リダイレクトを使わないのでエンドユーザに code や token が経由しない。
 エンドユーザと認証者は同じでなくても良い。例︓エンドユーザが⼦供で認証者が親。
 クライアント認証が必須の為に Confidential Client のみ利⽤可能。
 通常の認証処理と異なり⽬の前にいる顧客のアイデンティティ確認等への応⽤可。

53

LangEdge,Inc.

SCIM （System for Cross-domains Identity Management）
ユーザのアイデンティティ管理を⾏う為のプロトコル標準︓

RFC 7642（Overview）/ 7643（Core）/ 7644（Protocol）
最新仕様は SCIM2.0（2.0でXMLが⾮サポートに）、Slack や Azure AD 等が採⽤
http://www.simplecloud.info/

JSON ベースの RESTful API を使い標準化されている。
API︓ CRUD（⽣成/参照/更新/削除）、検索、同期、⼀括処理 等
スキーマ︓ ユーザとグループの最⼩限の定義と、拡張モデルを定義
認証認可︓ OAuth 2.0 を推奨（SCIM仕様には含まれない）
SCIM Actors

CSU

CSP

ECS

Cloud Service User

Cloud Service Provider

Enterpirse Cloud Subscriber

CSU

クラウドサービス間のプロビジョニング

企業ID管理システムからクラウドサービスへのプロビジョニング

Cloud Service User

CSU

CSP

ECS

Cloud Service User

Cloud Service Provider

Enterpirse Cloud Subscriber

CSU
Cloud Service User

※ プロビジョニング： ここではユーザの作成・削除や継続的な管理・保守をすること。

LangEdge,Inc.

まとめ…

54

LangEdge,Inc.

55

電子認証の要素技術まとめ
OAuth 2.0︓認可プロトコル標準

RESTful + JSON を使った認可を得る⼿順の標準仕様。
Access Token（認可チケット）を認可サーバから得る為の仕様。
Authorization Code Flow は code を得てから access_token に引換。
Implict Flow は直接 access_token を取得（セキュアにする為の⼯夫が必要）。

OpenID Connect︓OAuth 2.0 へのアイデンティティ層の追加

OAuth 2.0 の拡張仕様（JWT/JWSの仕様も参照）。
ID Token（認証結果の情報）を認可サーバから得る為の仕様。
属性情報取得の UserInfo 仕様の追加（ID Tokenでも属性取得は可能）。
属性情報 Claim と scope の標準仕様と、nonce 仕様の追加。

OAuth PKCE︓Authentication Code Flow の強化

code_verifier/code_challenge による認可コード横取り攻撃の対策。
認可サーバが正しい要求クライアントかを確認することを可能にする。

FIDO︓認証標準

状況に応じて認証強度とUXを選択できる認証標準（多要素認証にも対応）。
OAuth 2.0 + OpenID Connect との組み合わせで利⽤できる。

56

LangEdge,Inc.

最後にお疲れ様でした︕
本資料を読んで少しでも電⼦認証について分かった気になって頂けたならば幸いです。ただ電⼦認証を実現する為にはプロトコルの選定だけでは無くパラメータの考察や実装⽅法の検討も必要だと理解できたことと思います。難しいですね…、最後に幾つかの⾔葉を贈ります。
1. 実装時はめんどくさがらず必ず元仕様書を読み込みましょう。
2. 可能な限り独⾃実装では無く実績がある実装を利⽤しましょう。
3. オレが考えた最強の仕様はだいたいセキュリティの⽳があります。
標準化された仕様に従いましょう。
4. 分からないことは先達のブログや資料を検索しましょう。

Enjoy and Thank You !