世界一わかりみの深いOAuth入門 / wakarimioauth

© SIOS Technology, Inc. All rights Reserved.
世界⼀わかりみの深いOAuth⼊⾨
〜認可の基礎から応⽤まで〜
武井宜⾏
サイオステクノロジー株式会社
2021年5⽉14⽇

View Slide

⽬次
2
序章︓ OAuthをざっくり説明
第２章︓⾊んなフロー
第３章︓ リフレッシュトークン
第４章︓アクセストークン
第５章︓OAuthを認証に使うことの危険性
第６章︓stateパラメータによるCSRF対策

View Slide

About Me
3
BCPVUNF
Noriyuki TAKEI
෢Ҫ ٓߦ
Information
• サイオステクノロジー株式会社
• Microsoft MVP for Azure
Favorites
• Azure
• Squash
• Sweets
blog
https://tech-lab.sios.jp/
core skill
Cloud Native, Serverless全般
Twitter
@noriyukitakei

View Slide

本セッションの概要
4

View Slide

5
世界のどこよりもわかりみの深い
OAuth
を
お届けします。

View Slide

6
ハッシュタグ
#siospslive
もしくは
@noriyukitakei
に忌憚ないご意⾒
お願いいたします

View Slide

OAuthをざっくり説明
7

View Slide

8
ところで
よく聞くけど
OAuth
ってなに︖

View Slide

9
OAuthの特徴は以下のとおりです。
従来のID・パスワードベースとは異なる
トークンベースの認証
トークンには限られた権限だけを与えられているので、
万が⼀トークンが盗まれても被害が少ない
認可コードフローやImplicitフローにより
トークンを安全に取得
トークンには有効期限が設定されており、万が⼀トークンを
盗まれても有効期限過ぎると使えないので、セキュア

View Slide

10
よくわかりません。

View Slide

11
今回のセッションではこの4つの謎を⼀つづつ紐解いていきます。今回はこち
らです。
コレ
コレ

View Slide

12
新しいテクノロジーを理解しようとするときは、それに置き換わる従来のテ
クノロジーとの⽐較をすると、分かりやすいです。ということで以下の②つ
の認証⽅式を⽐較します。
ID・
パスワード
認証
従来のIDとパスワードによる認証です。Googleや
Office365等の外部サービスのAPIの呼び出しに⻑いこと使
われてきました。
OAuth
今回の肝であるトークンベースのイカした認証⽅式です。
最近はもっぱらこれ。

View Slide

13
以下のユースケースを考えてみます。Twitterにつぶやくと、⾃動的にそのつ
ぶやきがFacebookにも反映される仕組みです。
Twitterにつぶや
くと・・・
Facebookにも反
映される
⽩⾦なう
⽩⾦なう
Aさん

View Slide

14
ID・パスワード認証の場合

View Slide

15
Aさん
ユーザーID パスワード
[email protected] password
TwitterのシステムにAさん
のFacebookのユーザーID。
パスワードを登録します。

View Slide

16
Aさんがつぶやき
ます。
Aさん
⽩⾦なう

View Slide

17
Twitterのシステムに
登録されている
Facebookのユーザー
ID・パスワードを元
にFacebookに接続し
ます。
Aさん
ユーザーIDとパスワー
ドを送信

View Slide

18
TwitterがユーザーA
さんの代わりに
Facebookに投稿しま
す。
Aさん
⽩⾦なう

View Slide

19
Aさん
悪い⼈
投稿の削除、
退会など

View Slide

20
Aさん
悪い⼈
投稿の削除、
退会など
このしくみは、⼤きな弱点があります。TwitterにはAさんの
FacebookのユーザーID・パスワードが登録されています。
Twitterを運営している⼈に悪い⼈がいて、その⼈がAさんの
FacebookのID・パスワードで勝⼿にFacebookに接続でき
てしまいます。投稿の削除やアカウントの削除ができてしま
います。これを解決するのはOAuthです。OAuthは、
Twitter側にFacebookのユーザーID・パスワードを登録する
ことなく、Facebookに認証します。

View Slide

21
OAuthの場合

View Slide

22
OAuthの場合
Aさん Twitterシステム管理者
申請
■ ⼿順その1
Facebookへの申請
OAuthの認証の仕組みを説明します。まずTiwtterを運営するシステム管理者は、Facebookに対して、Oauthで接続
させてくださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が⽤意されてい
ます。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投稿)
を申請します。

View Slide

23
OAuthの場合
Aさん Twitterシステム管理者
申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をTwitterシステム管理者に発⾏します。ま
たTwitterから申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。Facebook、
Twitterは、そのクライアントID、クライアントシークレット、利⽤サービスを⾃⾝のデータベースに保存します。ここまでで
Twitterシステム管理者の仕事は終わりです。この作業はOAuth利⽤時にシステム管理者が最初の⼀度だけ⾏えばよい作業です。
クライアントID クライアントシークレット利⽤サービス
abcde hgjeoob2592lrmo post,view
■ ⼿順その2
クライアントID・シークレットの保存

View Slide

24
OAuthの場合
ここからは、利⽤者であるAさんがTiwitter→Facebook連携を⾏います。まず、Aさんは、Twitterにアクセスして、
Tiwitter→Facebook連携の設定画⾯にアクセスします。
Aさん
■ ⼿順その3
TwitterにFacebook連携の要求

View Slide

25
OAuthの場合
すると、Aさんは、Facebookにリダイレクトされて、Facebookの
ログイン画⾯が表⽰されます。このリダイレクトの際、URLのクエ
リパラメータにclient_idを付与します。次の⼯程でこれを使います。
Facebookログイン
ID
パスワード
送信
Aさん
■ ⼿順その4
Facebookログイン画⾯の表⽰
https://fb.example.com/authorize?responce_type=code&client_id=abcde&...

View Slide

26
OAuthの場合
ログインすると、Facebookは、Twitterと連携してもよいかどうかの確認画⾯
を表⽰します。Facebookは、多分、いろんなサービスとの連携を許可してい
ると思いますが、その多数あるサービスの中から、Twitterとの連携がOKかど
うかの画⾯を表⽰できたのは、先程リダイレクトの際にクエリパラメータに渡
されたクライアントIDから判断しています。
Aさん
Twitterと連携しても
いいですか︖
OK
■ ⼿順その5
認可画⾯の表⽰

View Slide

27
OAuthの場合
Aさんが先程の画⾯で「OK」をクリックすると、Twitterにリダイレクトされます。この際、認可コードというものが発⾏され
ます。リダイレクトされたときのURLのクエリパラメータにcode=…と⾔うかたちで、Twitterに渡されます。これは、後に
TwitterがFacebookにアクセストークンを要求するための、⾮常に有効期限の短い通⾏⼿形のようなものです。Facebookは認
可コード発⾏と同時に、認可コードを⾃⾝のデータベースに保存します。
Aさん
認可コード有効期限
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その6
Tiwtterへのリダイレクト with 認可コード
https://twitter.example.com/redirect?code=djlk9f2pkf

View Slide

28
OAuthの場合
TwitterはFacebookにアクセストークンを取得しに⾏きます。その際、先程発⾏された認可コードを渡します。
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
認可コード:djlk9f2pkf
■ ⼿順その7
アクセストークンの取得
⼀致しているか確認

View Slide

29
OAuthの場合
認可コードを要求されたFacebookは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がな
ければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したFacebook、アクセストークンを受け取った
Twitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。
Aさん
FacebookのID アクセストークン
[email protected] hloq239f9k1
TwitterのID アクセストークン
hloq239f9k1
■ ⼿順その8
アクセストークンの返却

View Slide

30
OAuthの場合
Aさんは、Twitterにつぶやきます。
Aさん
⽩⾦なう
■ ⼿順その9
Aさんのつぶやき

View Slide

31
OAuthの場合
TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookに
は、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータ
ベースから取得します。
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
hloq239f9k1
■ ⼿順その10
Facebookへの接続

View Slide

32
OAuthの場合
アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし⾒つかったら、それに紐づ
くユーザーIDで、Facebookに投稿します。これで、連携完了です。
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その11
連携完了︕︕

View Slide

33
OAuthの場合
再び悪い⼈の出番です。

View Slide

34
OAuthの場合
Twitterを運営する⼈の中に悪い⼈がいたとします。その悪い⼈がAさんのアカウントを悪⽤してFacebookのアカウントを削除
してやろうと考えました。
Aさん
悪い⼈

View Slide

35
OAuthの場合
でもそんな事できません。せいぜい以下みたいに変なことをつぶやくくらいです。このアクセストークンには、「利⽤サービ
ス」に登録されていること(この場合はpostとview)しかできないからです。そういう⾵にFacebook側で制御をかけているので
す。
Aさん
Twitter
A
お腹すいた
眠い
ほげ
Facebook
A
お腹すいた
眠い
ほげ
悪い⼈

View Slide

36
これがOAuthの最⼤のメリットです。ID・パスワー
ド認証をそのまま他のサービスに渡すと、どのよう
に使われるかわかりません。OAuthのトークンであ
れば、被害を最⼩限に済ませることができます。

View Slide

37
どうして認可コードを使うの︖⼿順が複雑になるし、
直接トークンを渡してくれればいいのに、、、。

View Slide

38
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その6
さっき説明したOAuthのフローで認可コードを渡すところです。このあとこ
の認可コードをもとにアクセストークンを要求します。

View Slide

39
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その7
こんな感じです。

View Slide

40
■ ⼿順その6
Tiwtterへのリダイレクト with アクセストークン
認可コード経由で渡すのではなく、直接アクセストークンを渡してはどうで
しょうか︖
https://twitter.example.com/redirect?code=hloq239f9k1
Aさん

View Slide

41
■ ⼿順その6
Tiwtterへのリダイレクト with アクセストークン
問題なさそうなのですが、アクセストークンが直接インターネットを流れる
ので、ハッカーがそれを奪う機会が多くなります。
https://twitter.example.com/redirect?code=hloq239f9k1
Aさん
スーパー
ハカー

View Slide

42
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その6
じゃぁ認可コードでも同じじゃんって感じです。が、認可コードはアクセストークンに
くらべて極端に短命です。OAuthの仕様では有効期限10分が推奨です。なので認可コー
ドを奪われたとしても、あまりにも短命なので、それを使って悪いことしようとしたと
きには期限切れて使えないということになります。
スーパー
ハカー

View Slide

43
ということで今回の章では、以下の2つについて説明しました。
コレ
コレ

View Slide

44
ということで繰り返しになりますが、ID・パスワード認証をそのまま他の
サービスに渡すと、どのように使われるかわからないのですが、OAuthの
トークンであれば、被害を最⼩限に済ませることができます。これがOAuth
を使うことの最⼤のメリットであり、これ以外の機能は極端に⾔うと、
OAuthの利⽤を補助するための機能でしかありません。なのでこの概念さえ
しっかり抑えておけばOAuth怖くないです。私もOAuth知らないことばかり
ですが、この概念をきっちり抑えたら、あとは仕様⾒て調べればいいやって
ことになり苦⼿意識が消えました。

View Slide

OAuthの登場⼈物
45

View Slide

46
「OAuthをざっくり説明」のところでは、説明の都合上、⾊々はしょって書い
てしまったので、改めてここで詳細を説明します。
リソースオーナーを認証し、アクセストークンを発⾏する
サーバーです。
認可サーバー
アクセストークンによる保護対象リソースを格納・提供す
るサーバーです。
リソースサーバー
リソースサーバーにアクセスして、アクセストークンを取
得するクライアントです。
クライアント
リソースサーバーで提供されるリソースの持ち主です。
リソースオーナー

View Slide

47

View Slide

48
先程紹介したOAuthの登場⼈物を「OAuthをざっくり説明」の図に当てはめて
みます。これでイメージが湧くかと思います。
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう
クライアント
認可サーバー＆リソースサーバー

View Slide

49
ここからの説明の都合上、「OAuthをざっくり説明」で説明した流れを1枚のス
ライドにまとめました。
リソース
オーナー
クライアント
認可サーバー＆
① 認可リクエスト
ID
パスワード
送信
② ID・パスワード
⼊⼒して認証
③ クライントにリダイレクト
with 認可コード
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
④ 認可コードで
アクセストークンを
リクエスト
⑤ アクセストークン
を取得
⑥ アクセストークン
でリソースを取得
「OAuthをざっくり説
明」でいうところのAさん
「OAuthをざっくり説明」
でいうところのFacebook
でいうところのTwitter

View Slide

50
先程の図で認可サーバーとリソースサーバーが⼀緒になっていました。Facebookが認可も
リソースの提供もやっていたのですが、実はこれが別々になるケースが最近はよくありま
す。その時の流れは以下の通りとなります。
リソース
オーナー
クライアント
認可サーバー
ID
パスワード
送信
⼊⼒して認証
認可
コード
認可
コード
アクセス
トークン
リクエスト
を取得
アクセス
トークン

View Slide

51
どうして認可サーバーとリソースサーバーが分かれることがあるのでしょうか︖それは、
最近「IDaaS」というのがはやっているからです。IDaaSの特徴は以下の通りとなります。
認証・認可のみに特化したSaaS型のマネージドサービス
ワンタイムパスワードや証明書認証な
様々な認証⽅法を提供
Azure Active DirectoryやAuth0が有名

View Slide

52
例えば⾃社開発のオンラインストレージサービスを開始したいとします。でも、認証・認
可の機能を作り込むのは超⼤変です。そこをIDaaSに任せてしまえば、餅は餅屋というこ
とで、認証・認可はIDaaSに任せて、⾃社のサービス開発に専念できます。
リソース
オーナー
クライアント
Azure Active Directory
ID
パスワード
送信
⼊⼒して認証
認可
コード
認可
コード
アクセス
トークン
リクエスト
を取得
オンラインストレージ
アクセス
トークン
⾃社開発で
頑張る︕︕
アクセストークンを⽣成す
る認可基盤はIDaaSである
Azure Active Directoryに
おまかせ︕︕

View Slide

⾊んなフロー
53

View Slide

⾊んなフロー
54
今回は、アクセストークンを取得するためのいろんなフローについて説明し
ます。
コレ

View Slide

⾊んなフロー
55
OAuthにはアクセストークンを取得するための3つの代表的なフローが存在し
ます。
クライアントIDとクライアントシークレットを投げるとアクセストークン
が返ってきます。主にバッチ処理向けフローです。
クライアント
クレデンシャルズ
フロー
スマホアプリやブラウザ上のJava Scriptで動くネイティブアプリから直接
アクセストークンを発⾏する必要があるときのフローです。
※ ただし現在は⾮推奨︕︕
インプリシット
フロー
主にWebアプリケーション向けのフローで、認可コードフローをやり取り
して、アクセストークンを取得します。
認可コードフロー

View Slide

⾊んなフロー
56
認可コードフロー
「OAuthをざっくり説明」のところで説明したフローが、認可コードフローになります。
リソース
オーナー
認可サーバー＆
ID
パスワード
送信
⼊⼒して認証
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
リクエスト
を取得
「OAuthをざっくり説
明」でいうところのAさん
でいうところのFacebook
でいうところのTwitter

View Slide

⾊んなフロー
57
インプリシットフロー
Aさん
(リソースオーナー)
アプリの開発者
申請
■ ⼿順その1
インプリシットの流れを説明します。ここではAさん(リソースオーナー)内のスマホアプリ(クライアント)が、Facebook(リ
ソースサーバー＆認可サーバー)の投稿⼀覧を取得するようなユースケースを考えてみます。まずアプリの開発者は、Facebook
に対して、Oauthで接続させてくださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が
⽤意されています。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投
稿)を申請します。
Aさんのスマホ内のアプリ
(クライアント)
Facebook
(認可サーバー＆リソースサーバー)

View Slide

⾊んなフロー
58
申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をアプリの開発者に発⾏します。またアプリ
の開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。Facebookは、その
クライアントID、クライアントシークレット、利⽤サービスを⾃⾝のデータベースに保存します。ここまででアプリの開発者の
仕事は終わりです。この作業はOAuth利⽤時にアプリの開発者が最初の⼀度だけ⾏えばよい作業です。
■ ⼿順その2

View Slide

⾊んなフロー
59
ここでちょっとこの⼿順について追加の説明をします。インプリシットフローでは、クライアントID・クライアントシークレッ
トは、クライアント(この場合だとスマホアプリ)に保存しません。なぜならば、インプリシットフローの場合は、クライアント
であるスマホに、リソースオーナーが簡単にアクセスできます。つまりリソースオーナーがクライアントシークレットを取得で
きます。もしクライアントID・クライアントシークレットをスマホに保存すると、クライアントID・クライアントシークレット
はかなり強い権限を持っているので(詳細は後述)、複数のリソースオーナー(アプリ使う⼈)が強い権限を持ってしまうためです。
■ ⼿順その2
クライアントID クライアントシークレット
abcde hgjeoob2592lrmo
・
・
・・
・
・

View Slide

⾊んなフロー
60
Aさん
クライアント
認可サーバー＆リソースサーバー
ちなみに認可コードフローの図を以下に再掲しますが、この場合は、リソースオーナー(Aさん)はクライアント(Twitter)の中に
あるクライアントIDとクライアントシークレットにアクセスできません。これはTwitterのサーバーの中に保存されているため
です。なので認可コードフローでは、クライアントIDとクライアントシークレットをクライアントの中に保存します。

View Slide

⾊んなフロー
61
ということで、インプリシットフローに話を戻します。スマホアプリ内の埋め込みブラウザが、Facebookのログイン画⾯にア
クセスします。
■ ⼿順その3
Facebookログイン画⾯の表⽰
ID
パスワード
送信
https://fb.example.com/authorize?responce_type=token&client_id=abcde&...

View Slide

⾊んなフロー
62
ここでちょっとこの⼿順について追加の説明をします。Facebook(認可サーバー)の認証画⾯にアクセスするためのURLについ
ては先のページの通り以下になります。ここの書式はOAuthの仕様である程度決まっています。⼀般的にこのURLは「認可エン
ドポイント」と呼ばれており、その詳細は以下の通りとなります。
https://fb.example.com/authorize?responce_type=token&client_id=abcde&...
認可エンドポイントのURLです。これはリ
ソースサーバー(FacebookやAzure Active
Directoryなど)ごとに決まっています。
response_typeというクエリパラメーター
は、これから実施されるフローを決定づけ
るものです。tokenはインプリシットフ
ローを表します。これがcodeだと認可
コードフローになります。
クライアントIDを指定します。こ
の値が認可サーバーに渡されて、
対応したクライアントIDに紐づく
処理を⾏います。

View Slide

⾊んなフロー
63
Facebook(認可サーバー)での認可が完了すると、事前にFacebook(認可サーバー)で設定したリダイレクトURIにリダイレクト
されます。ここまでは認可コードフローと同じなのですが、違いはリダイレクトURIのハッシュフラグメント(#以降)に
access_tokenというパラメータが付いていることであり、これがアクセストークンを表しています。
■ ⼿順その4
クライアントへのリダイレクト with アクセストークン
https://client.example.com/redirect#access_token=sohg9ba&...
これがアクセストークン

View Slide

⾊んなフロー
64
スマホアプリ(クライアント)は、先程のリダイレクトURIを解析して、ハッシュフラグメントからアクセストークンを取得して、
スマホアプリ内に保存します。
■ ⼿順その5
アクセストークンの取得と保存
[email protected] sohg9ba

View Slide

⾊んなフロー
65
スマホアプリ(クライアント)は、Facebook(リソースサーバー)にアクセストークンと送るとともに、投稿の⼀覧を要求します。
■ ⼿順その6
sohg9ba

View Slide

⾊んなフロー
66
スマホアプリ(クライアント)は、Facebook(リソースサーバー)にから投稿の⼀覧を受け取ります。
■ ⼿順その7
結果の取得
A
お腹すいた
眠い
⽩⾦なう

View Slide

⾊んなフロー
67
インプリシットフローのポイントは以下のとおりです。
認可コードフロートは異なり、認可サーバーへの認証完了の
レスポンスで、ダイレクトにアクセストークンを受け取る
アクセストークンがクライアント(スマホアプリ)⇔認可サーバー
(Facebook)間を流れる、つまりパブリックなネットワーク上に流れるので、
漏洩のリスクが認可コードフローより⾼い。
インプリシットフローにはいくつかの脆弱性があり(後述)、今は⾮推奨。
スマホアプリのようなネイティブアプリでも認可コードフローを⽤いる。

View Slide

⾊んなフロー
68
クライアントクレデンシャルズフロー
バッチの開発者
申請
■ ⼿順その1
クライアントクレデンシャルズフローの流れを説明します。ここではバッチの開発者(リソースオーナー)が開発したバッチプロ
グラムをバッチ処理サーバー(クライアント)に置いて、そのバッチプログラムからFacebook(認可サーバー＆リソースサーバー)
の投稿⼀覧を取得するようなユースケースを考えてみます。まずバッチ開発者は、Facebookに対して、Oauthで接続させてく
ださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が⽤意されています。その申請
フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投稿)を申請します。
バッチ処理サーバー
Facebook

View Slide

⾊んなフロー
69
■ ⼿順その2
申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をバッチ開発者に発⾏します。またバッチ開
発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。Facebookは、そのクラ
イアントID、クライアントシークレット、利⽤サービスを⾃⾝のデータベースに保存します。そしてバッチの開発者は受領した
クライアントIDとクライントシークレットを、バッチ処理サーバーに保存します。この作業はOAuth利⽤時にバッチの開発者が
最初の⼀度だけ⾏えばよい作業です。
Facebook
クライアントID
クライアントシークレット
受領
登録

View Slide

⾊んなフロー
70
■ ⼿順その3
アクセストークンの要求
バッチ処理サーバー内のバッチプログラムは、クライアントIDとクライアントシークレットを渡して、アクセストークンを要求
します。
Facebook

View Slide

⾊んなフロー
71
■ ⼿順その3
Facebook(認可サーバー)は、クライアントIDとクライアントシークレットが正しいものであることが確認できたら、バッチ処
理サーバー(クライアント)にアクセストークンを返します。
sohg9ba

View Slide

⾊んなフロー
72
■ ⼿順その4
アクセストークンでリソースの要求
バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場
合はFacebook投稿の⼀覧)を要求します。
sohg9ba

View Slide

⾊んなフロー
73
■ ⼿順その5
リソースの返却
Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアン
ト)にFacebookの投稿⼀覧(リソース)を返します。
A
お腹すいた
眠い
⽩⾦なう
リソース

View Slide

⾊んなフロー
74
クライアントクレデンシャルズフローのポイントは以下のとおりです。
クライアントIDとクライアントシークレットで
アクセストークンを取得する。
クライアントIDとクライアントシークレットは強い権限を持つので
信頼できる相⼿にしか渡さない。この場合は、バッチの開発者地震
が管理しているサーバーなので問題はない。
バッチ処理のような場合、ブラウザが介在しないので、認可コードフローや
インプリシットフローは当てはまらない。リソースーオーナーが信頼できる
クライアントとリソースサーバーの間で⽤いる。

View Slide

⾊んなフロー
75
今回は、以下の内容を説明しました。
コレ

View Slide

⾊んなフロー
76
ここからはちょっと補⾜的なことを説明します。以下の図を覚えていますか︖クライア
ントクレデンシャルズフローで、クライアントシークレットは不特定多数のひとにばら
まいてはいけないと説明しました。それはクライアントシークレットが強⼒な権限を持
つからなのでが、それは先のクライアントクレデンシャルズフローで説明したように、
クライアントクレデンシャルズフローではクライントIDとクライアントシークレットで
アクセストークンを取得できます。なので権限が強⼒なのです。
■ ⼿順その2
・
・
・・
・
・

View Slide

⾊んなフロー
77
いろいろなフローをご説明しました。まずは最も利
⽤頻度の⾼い(と思われる)認可コードフローを抑え
ておけば⼤丈夫かと思います。他のフローは、認可
コードフローに⽑が⽣えたようなものですので。

View Slide

⾊んなフロー
78
おまけで
リソースオーナーパスワードクレデンシャルズフロー
というものを説明します。
基本は、クライアントクレデンシャルズフローと変わ
りませんが、クライアントID・クライアントシーク
レットの代わりにユーザー名とパスワードを渡します。

View Slide

⾊んなフロー
79
申請
■ ⼿順その1
ここではバッチの開発者(リソースオーナー)が開発したバッチプログラムをバッチ処理サーバー(クライアント)に置いて、その
バッチプログラムからFacebook(認可サーバー＆リソースサーバー)の投稿⼀覧を取得するようなユースケースを考えてみます。
まずバッチ開発者は、Facebookに対して、Oauthで接続させてくださいみたいな事前の申請をします。これは、Facebookなど
のサービスに申請専⽤の画⾯が⽤意されています。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebook
に対して⾏いたい作業(閲覧や投稿)を申請します。
Facebook

View Slide

⾊んなフロー
80
■ ⼿順その2
申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をバッチ開発者に発⾏します。またバッチ開
発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。Facebookは、そのクラ
イアントID、クライアントシークレット、利⽤サービスを⾃⾝のデータベースに保存します。そしてバッチの開発者は、
Facebookにログインするためのユーザー名とパスワードをバッチ処理サーバーに登録します。
Facebook
Facebookのユーザー名
Facebookのパスワード
登録
Facebookのユーザー名 Facebookのパスワード
[email protected] hogehoge

View Slide

⾊んなフロー
81
■ ⼿順その3
アクセストークンの要求
バッチ処理サーバー内のバッチプログラム(クライアント)は、Facebook(リソースサーバー)にリソースオーナーのユーザー名と
パスワードを渡します。
Facebook

View Slide

⾊んなフロー
82
■ ⼿順その3
Facebook(認可サーバー)は、ユーザー名とパスワードが正しいものであることが確認できたら、バッチ処理サーバー(クライア
ント)にアクセストークンを返します。
sohg9ba
Facebookのユーザー名 Facebookのパスワードアクセストークン
[email protected] hogehoge sohg9ba

View Slide

⾊んなフロー
83
■ ⼿順その4
アクセストークンでリソースの要求
バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場
合はFacebook投稿の⼀覧)を要求します。
sohg9ba

View Slide

⾊んなフロー
84
■ ⼿順その5
リソースの返却
Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアン
ト)にFacebookの投稿⼀覧(リソース)を返します。
A
お腹すいた
眠い
⽩⾦なう
リソース

View Slide

⾊んなフロー
85
このフローのメリットは、仮にOAuth適⽤前に基本認証(ユーザーIDとパスワードによる認証)を使っていて、OAuthに移⾏した
としても、バッチ処理サーバー(クライアント)がFacebookに渡す情報は変わらないということです。ということは、OAuthに
変更下としても、バッチ処理サーバーのSDKのバージョンだけ上げれば、そのままFacebookに渡す情報を変えることなく
OAuth対応できます。
Facebook
Facebook
OAuth適⽤前 OAuth適⽤後

View Slide

⾊んなフロー
86
このフローのメリットは、仮にOAuth適⽤前に基本認証(ユーザーIDとパスワードによる認証)を使っていて、OAuthに移⾏した
としても、バッチ処理サーバー(クライアント)がFacebookに渡す情報は変わらないということです。ということは、OAuthに
変更したとしても、バッチ処理サーバーのSDKのバージョンだけ上げれば、そのままFacebookに渡す情報を変えることなく
OAuth対応できます。
Facebook
Facebook
OAuth適⽤前 OAuth適⽤後

View Slide

⾊んなフロー
87
マイクロソフトもExchange Onlineの認証を基本認証からトークンベースのOAuth認証(マイクロソフト的には先進認証という
らしいです)への移⾏を進めています。ただし、旧モジュールとの互換性を保つために、以下のURLにあるようにPowerShellの
バージョンだけ⼊れ替えると、従来どおり基本認証(ユーザー名とパスワードを渡す⽅式)の形式を維持したまま、裏ではトーク
ンベースの認証が⾏われているということです。まさしくこのモジュールはリソースオーナーパスワードクレデンシャルズフ
ローを使っていると推測されます。
Exchange Online PowerShell V2 モジュールのバージョン情報
https://docs.microsoft.com/ja-jp/powershell/exchange/exchange-online-powershell-
v2?view=exchange-ps
ただし、マイクロソフト的には、この⽅法は⾮推奨のようです。この⽅法だと、せっかくOAuthにしたのに、
アプリケーション内にユーザー名とパスワードが埋め込まれることとなり漏洩のリスクが⼤きく、OAuthにし
た意味がないということなのかもしれません。

View Slide

リフレッシュトークン
88

View Slide

89
今回は、以下のポイントについて説明します。
コレ

View Slide

90
リフレッシュトークンの概要は以下のとおりです。
アクセストークンは超短命(1時間程度)であり、短命で
あるがゆえに漏洩したときのリスクを抑えている。しか
し、アクセストークンの有効期限を過ぎた場合に認可サ
ーバーに再認証してもう⼀度アクセストークンを取得す
るのは⾮常にユーザビリティに⽋けるため、リフレッシ
ュトークンを認可サーバーに送るだけでアクセストーク
ンを再取得できる。

View Slide

91

View Slide

92
では、ここでもリフレッシュトークンがない場合とリフレッシュトークンがある場合を
くらべて、どんな点が良くなるのかを⽐較してみたいと思います。以下の図は、
「OAuthをざっくり説明」で説明したもので、すでにアクセストークンを取得済みであ
ることを表した図です。これをベースに説明します。
Aさん
⽩⾦なう
■ ⼿順その9

View Slide

93
ではまず、リフレッシュトークンがない世界ではどのような不便なことがおこるのか説明します。AさんはTwitterに「⽩⾦な
う」とつぶやきます。
Aさん
⽩⾦なう
リフレッシュトークンがない世界

View Slide

94
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Twitter(クライアント)からFacebook(リソースサーバー)にアクセストークンが渡されて、TwitterはFacebookのAPIを実⾏する
ことができて、TwitterのつぶやきがFacebookにも反映されます。
Facebook
A
お腹すいた
眠い
⽩⾦なう
hloq239f9k1

View Slide

95
Aさん
もう⼀度Twitterにつぶやいてみました。でも今度はアクセストークンの有効期限が切れてエラーになってしまいました。
hloq239f9k1
✗
⽩⾦なう

View Slide

96
Aさん
しょうがないので、もう⼀度Facebook(認可サーバー)での認証からやり直してアクセストークンを取得するところからやり直
そう。。。って事になります。でも、アクセストークンが切れるたびにこんな事するのめんどくさいですよね。なんとかしたい
ものです。
Facebookログイン
ID
パスワード
送信

View Slide

97
そこでリフレッシュトークンがある世界です。実はFacebook(認可サーバー)での認証が終わって、Facebookからアクセストー
クンが発⾏されると同時にリフレッシュトークンも発⾏されます。
Aさん
FacebookのID アクセストークンリフレッシュトークン
[email protected] hloq239f9k1 aq9vl02pf
TwitterのID アクセストークンリフレッシュトークン
リフレッシュトークンがある世界
hloq239f9k1
aq9vl02pf
アクセストークン

View Slide

98
ちなみに認可サーバーから返されるアクセストークンとリフレッシュトークンは以下のようなJSON形式であることが多いです。
access_tokenのフィールドの値がアクセストークン、 refresh_tokenのフィールドの値がリフレッシュトークンです。
{
“access_token”:“2YotnFZFEjr1zCsicMWpAA”,
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value”
}

View Slide

99
アクセストークンとリフレッシュトークンを取得した状態でTwitterにつぶやいてみます。
Aさん
⽩⾦なう

View Slide

100
通常通りTwitterにもFacebookにも反映されます。
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう
hloq239f9k1

View Slide

101
アクセストークンの有効期限が切れてリクエストがエラーになってしまいました。
Aさん
hloq239f9k1
✗

View Slide

102
Twitter(クライアント)はリフレッシュトークンをFacebook(認可サーバー)に送ります。
Aさん
aq9vl02pf
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう

View Slide

103
リフレッシュトークンを受け取ったFacebook(認可サーバー)は、アクセストークンとリフレッシュトークンを再作成して、
Twitter(クライアント)に返します。
Aさん
[email protected] uom2ch28 lkqo8mvnb
[email protected] uom2ch28 aq9vl02pf
uom2ch28
lkqo8mvnb

View Slide

104
新しく⽣成されたアクセストークンで再度Facebook(リソースサーバー)にアクセスします。今度はちゃんと正常にアクセスで
きました︕︕
Aさん
[email protected] uom2ch28 lkqo8mvnb
[email protected] uom2ch28 aq9vl02pf
uom2ch28
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう

View Slide

105
リフレッシュトークンなんてめんどくさい仕組み使
わずに、アクセストークンの有効期限をとても⻑く
(例えば6ヶ⽉位とか)してしまえばいいのではない
ですか︖

View Slide

106
アクセストークンの有効期限を⻑くするのはNGです。アクセストークンはリソースサー
バーにリクエストを送るたびにネットワーク上を流れます。ということはとても頻繁に
ネットワークを流れることになり漏洩のリスクに晒されているのです。
Twitter
Facebook
(リソースサーバー)
アクセストークン(有効期限:6ヶ⽉)

View Slide

107
Twitter
Facebook
スーパーハカー
盗聴
アクセストークンを盗んだハッカーは、⽤意にFacebookの情報を操作できてしまいます。
有効期限が超⻑いからです。

View Slide

108
Twitter
Facebook
アクセストークン(有効期限:1時間)
スーパーハカー
盗聴
でもアクセストークンの有効期限を短くしておけば、たとえハッカーに盗まれたとして
も1時間後には使えなくなるので、悪⽤されるリスクが減るわけです。
✗期限切れ(><)

View Slide

109
Twitter
Facebook
リフレッシュトークン(有効期限:6ヶ⽉)
リフレッシュトークン(有効期限:6ヶ⽉)
リフレッシュトークンもアクセストークンと同じくネットワーク上を流れます。そして
リフレッシュトークンはアクセストークンよりも有効期限は⻑いです。ただ、リフレッ
シュトークンはアクセストークンよりもネットワーク上を流れる頻度が少ないので、漏
洩のリスクが少ないので、有効期限は⻑くても⽐較的⼤丈夫なのです。

View Slide

110
今回は、以下のポイントについて説明しました。
コレ

View Slide

111

View Slide

112
アクセストークンは、OAuthの仕様では、その形式を定めておりませんが、
主に以下の形式を取ります。
タイプA
アクセストークンの中にアクセストークンに関する情報を
内包せず、やり取りされる情報はアクセストークンを⼀意
に識別する識別⼦のみで、アクセストークンに関する情報
はデータベースなどに保存する。
タイプB
アクセストークンに関する情報をアクセストークンの中に
内包する形式

View Slide

113
タイプA︓アクセストークンの中に情報を含まない場合
まずはタイプAのパターンについて説明します。ここで認可コードフローをちょっとおさらいします。認可コードフローでアク
セストークンを取得するためには、認可コードをFacebook(認可サーバー)にリクエストしないとダメなのでした。なので、発
⾏された認可コードを渡します。
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その7

View Slide

114
認可コードを要求されたFacebookは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がな
ければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したFacebook、アクセストークンを受け取った
Twitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。
Aさん
hloq239f9k1
■ ⼿順その8

View Slide

115
Aさん
⽩⾦なう
■ ⼿順その9

View Slide

116
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
hloq239f9k1
■ ⼿順その10

View Slide

117
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その11
連携完了︕︕

View Slide

118
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
Facebook
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その11
連携完了︕︕

View Slide

119
リソース
オーナー
クライアント
認可サーバー
ID
パスワード
送信
⼊⼒して認証
認可
コード
認可
コード
アクセス
トークン
リクエスト
を取得
アクセス
トークン
では先程御説明したように認可サーバーとリソースサーバーが別々だった場合はどうで
しょうか︖

View Slide

120
認可サーバーとリソースサーバーが別々になった場合を考えてみます。以下は認可サーバーはマイクロソフトが提供するAzure
Active Directory、リソースサーバーはFacebookという構成になります。この構成で、もう⼀度認可コードをリクエストする
ところから流れを追ってみたいと思います。なので、発⾏された認可コードを渡します。
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その7

View Slide

121
認可コードを要求されたAzure Active Directoryは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確
認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したAzure Active Directory、アク
セストークンを受け取ったTwitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。
Aさん
hloq239f9k1
■ ⼿順その8

View Slide

122
Aさん
⽩⾦なう
■ ⼿順その9

View Slide

123
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その10
hloq239f9k1 アクセストークン

View Slide

124
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その10
hloq239f9k1
さて、ここからが問題なのですが、アクセストークンを受け取ったFacebook(リソースサーバー)はそのアクセストークンが正
しいものかどうか確かめたいので、Azure Active Directory(認可サーバー)のアクセストークンと⽐較したいですが、通常
Azure Active DirectoryはFacebookとは全然異なるネットワークにあるため、直接データベースの中を⾒ることができません。
✗
認可サーバーとリソースサーバーが
同じであれば、同じデータベースを
共有するので、アクセストークンの
正当性を確認するのも簡単だが、別
れている場合は難しい。

View Slide

125
そこで
JSON Web Token
です

View Slide

126
ちょっとJSON Web Tokenのことについて話す前に以下の前提知識が必要が
ありますので、ちょっと横道にそれますが、お付き合いください。まずは秘
密鍵暗号化⽅式からです。
公開鍵暗号化⽅式
公開鍵暗号化⽅式による
改ざん防⽌
⾝分証明
秘密鍵暗号化⽅式
コレ

View Slide

127
お互いに同じ暗号化の鍵を共有して、暗号・複合する⽅式です。暗号化・復号化に使う鍵は同じです。鍵を相⼿に渡すときは、
盗聴されないよう、郵送などの⼿段を取る必要があります。

A

View Slide

128
次に公開鍵暗号化⽅式です。
改ざん防⽌
⾝分証明
コレ

View Slide

129
公開鍵暗号化⽅式は、
暗号に使う鍵と、復
号に使う鍵がそれぞ
れ異なる暗号化⽅式
です。Bさんの公開鍵
を取得して、Aさんは、
その公開鍵で⽂書を
暗号化します。その
⽂書を受け取ったBさ
んは、⾃分の秘密鍵
で復号します。

B B
D C
A

b
D C
A
D C
A

W B W
W A E
A e
e
A
B
e

View Slide

130
秘密鍵暗号化⽅式だと、例えば下記例のようにAさんが、BさんとCさんとDさんに暗号化した⽂書を渡したい時に、郵送など絶
対に盗聴されない⼿段で、それぞれの⼈にAさんの秘密鍵を渡さないといけません。⾮常に⾯倒です。

View Slide

131
公開鍵暗号化⽅式を使えば、インターネットなどで公開されているBさん、Cさん、Dさんの公開鍵を取得して、それで暗号化す
ればOKです。公開鍵が通信経路で盗聴されたとしても、秘密鍵され漏洩しなければ、暗号化した⽂書は安全です。公開鍵暗号化
されたものは、秘密鍵でしか復号できないからです。

View Slide

132
次に公開鍵暗号化⽅式による改ざん防⽌です。
改ざん防⽌
⾝分証明
コレ

View Slide

133
公開鍵暗号化⽅式を
使えば、暗号化した
⽂書が通信経路の途
中で改ざんされてい
ないかどうかを検知
することが可能です。
公開鍵暗号化⽅式による改ざん防⽌

A
A
A
A

View Slide

134
改ざんされると以下
のような結果になり、
改ざんされたことを
検知できます。
公開鍵暗号化⽅式による改ざん防⽌
(

)

(

)
(
)
)
)

A
1

View Slide

135
次に公開鍵暗号化⽅式による⾝分証明です。
改ざん防⽌
⾝分証明
コレ

View Slide

136
電⼦証明書を使えば、
インターネットの世
界で⾝分証明を⾏う
ことが出来ます。リ
アルな世界の印鑑証
明みたいなものです。
市役所に相当するの
が認証局になります。
公開鍵暗号化⽅式による⾝分証明
S
S

I
( )
S
O(
I
)
S S
S
)
O)

View Slide

137
SIOS商店が取得した
電⼦証明書は、俗に
いうSSL証明書にな
ります。SIOS商店の
ネットショップに、
IDとパスワードを送
る仕組みは以下のと
おりです。
公開鍵暗号化⽅式による⾝分証明

h g
n a
S
O
$
$
S
O
&
- .- . . .
. .
(#

n a D
)"
%

S
O
'
n a D
- .- . . .
. .
! $
*
h g c o
a
D @ m
e
I
2

View Slide

138
いよいよ
JSON Web Tokenの
説明になります。

View Slide

139
まことにざっくりとした説明ですが、JSON Web Tokenの特徴は以下のとおりです。
JSON Web Token
JSON Web Tokenとは、アクセストークンが正しいかどうかをチェックする仕
組みです。
JSON Web Tokenは、もっと専⾨的な⽤語を使いますと、JSONに電⼦署名を
⾏い、必要に応じてそのJSONの検証を⾏い、認証可否を決定する仕様です。
OpenIDやOAuthなどに⽤いられている標準的な仕様です。

View Slide

140
JSON Web Tokenとは、以下のような形式です。
JSON Web Token
eyJhb...(omit)...XVCJ9.e-KAnH ...(omit)... igJ19.977635 ...(omit)... ad
ヘッダーペイロードヘッダーとペイロードを
ピリオドでつないで署名
したもの
ピリオドピリオド

View Slide

141
JSON Web Tokenのヘッダーは、以下のような形式です。
JSON Web Token
{
“alg”: ”HS256”,
“typ”: “JWT”
}
署名アルゴリズムで、
HS256であることを
表す。
トークンのタイプで
JSON Web Tokenで
あることを表す。

View Slide

142
JSON Web Tokenのペイロードは、以下のような形式です。例えばユーザー名だったり、認可情報だったり、ユーザーが⾃由
に定義します
JSON Web Token
{
“sub”: “ntakei”
}
これは、ユーザー名がntakeiのデータになります。
ただ、何でも定義していいというわけではなく、幾
つかのフィールド名はJSON Web Tokenの仕様に
よって予約されています。

View Slide

143
認可サーバー側
では右図のよう
な形式でアクセ
ストークンが作
成されます。
JSON Web Token
{
:“ ”
: 2
}
I
D4 : 6:
J
6 6 : : H
H , 5A
4H OOO
(
. (
. (
{
:“ ”
: 2
}
I
D4 : 6:
J
(
{ :“ ”
: 2 } I D4
6: J
w h bPWi
lPd gk d U
N
x h bPWi lPd
gk d U T M
e ajmS N
. :6 5
)
y nq PfP s
Tp ut
mS N

View Slide

144
リソースサーバーでは
アクセストークンを右
図のように検証します。
JSON Web Token
{
O A :“,3 (”
O KD : .64
}
M
O H : O
N
K. 2 J24 2
0 0 I 5 9
. SSS
)(
.
) ) ( SSS
) ) ( SSS
mhgT n Tia kq
di zu a3, (
jhf xW
blqeTfps
}w ya x
W
“ a
t
U {
2 W

View Slide

145
横道にそれましたが
「タイプB︓アクセストークンの中に情報を含む場合」
の説明をしたいと思います。

View Slide

146
タイプAで認可サーバーとリソースサーバーが別れている場合は、リソースサーバー側でアクセストークンの確認ができません
でした。これをJSON Web Tokenにした場合の流れについて説明します。認可サーバーとリソースサーバーが別々になった場
合を考えてみます。以下は認可サーバーはマイクロソフトが提供するAzure Active Directory、リソースサーバーはFacebook
という構成になります。この構成で、もう⼀度認可コードをリクエストするところから流れを追ってみたいと思います。なの
で、発⾏された認可コードを渡します。
Aさん
djlk9f2pkf 2018年3⽉4⽇ 15:00
■ ⼿順その7
タイプB︓アクセストークンの中に情報を含む場合
加えて、Azure Active Directory(認可サー
バー)とFacebook(リソースサーバー)の間
で事前にアクセストークンを署名・検証す
るための共有鍵が管理者によって登録され
ているものとします。(実際は公開鍵暗号
化⽅式でやっていると思うので、その必要
はないと思いますが、説明を簡単にするた
め事前に共有鍵を交換するものとします)

View Slide

147
認可コードを要求されたAzure Active Directoryは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確
認し、問題がなければ、TwitterにJSON Web Token形式のアクセストークンを返します。タイプAと違うのは、Azure Active
Directory側(認可サーバー)側にアクセストークンを保存していません。
Aさん
[email protected] XXX.YYY.XXX
XXX.YYY.ZZZ
■ ⼿順その8

View Slide

148
認可サーバー側でア
クセストークンが作
成される際、右図の
ような流れで作成さ
れます。
{
4 M:“ ”
DHAM:M M
}
J
5M: 4 4 M
H : . . I.
, ,I - 2D4 6
5I PPP
)
.
.
{
4 M:“ ”
DHAM:M M
}
)
J
5M: 4 4 M
{ 4 M:“ ” DHA
M:M M} J 5
4 4 M
x id j
m e hl eW
O
y id j m e
hl eW U N
WfdbknT O
4: 6
(
z a g ts
SUqpwW un
T O

View Slide

149
Aさん
⽩⾦なう
■ ⼿順その9
ということで、アクセストークンが無事作成されたので、まず、Aさんは、Twitterにつぶやきます。

View Slide

150
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
■ ⼿順その10
XXX.YYY.XXX アクセストークン

View Slide

151
受け取った
Facebook(リソース
サーバー)は右図のよ
うな流れでアクセス
トークンが正しいか
どうかを検証します。
{
S9D T:“.5 ()”
SKOHT:T0 6T
}
SJ T: S9 J9FT
O0 F A4A N46 4
,2 2 M3 K9 I
0 WWW
)(
.
I ) WWW
I ) WWW
ml sf ne qu
gn }x bae5. ()
omit{ d
uk jh p
-9 z
“ e { d
ya e
Uw
cU
4 d

View Slide

152
Aさん
Twitter
A
お腹すいた
眠い
⽩⾦なう
無事連携完了できました。タイプAと異なり、Facebook(リソースサーバー)は、JSON Web Token形式のアクセストークンを
検証することで、Facebookは、Azure Active Directoryなど他のシステムにアクセスすることなく、アクセストークンを検証
することができました︕︕
■ ⼿順その11
連携完了︕︕
Facebook
A
お腹すいた
眠い
⽩⾦なう

View Slide

OAuthを認証に使うことの危険性
153

View Slide

154
本章では、OAuthを認証に使うことの危険性について説明したいと思います。
これはある特定の条件下で発⽣します。
インプリシットフローを使っている
アクセストークンの発⾏元を検証していない
プロファイル情報APIによって得たユーザー情報を
認証ユーザーとしている

View Slide

155
では実際にやってみましょう。では通常のOAuth認証の流れについて説明し
ます。登場⼈物は以下のとおりです。
Aさん
格ゲーX
ゲーム開発者
格ゲーXをやる善良な市⺠です。
とあるゲームプラットフォームのも
とで開発された善良なスマホ⽤格闘
ゲームです。
格ゲーXを開発している善良な開発
者です。
ゲーム
プラットフォーム
ゲームを開発するためのプラットフ
ォームです。LINEとかが有名です。

View Slide

156
まず格ゲーXを開発するゲーム開発者は、ゲームプラットフォームに対して、OAuthで接続させてくださいみたい
な事前の申請を専⽤の申請フォームより⾏います。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、
ゲームプラットフォームに対して⾏いたい作業(閲覧や投稿)を申請します。この場合は、アクセスしてきたユー
ザーのプロファイル情報(ユーザー情報や名前など)を操作できる権限を申請します。
ゲーム開発者
申請
格ゲーX
ゲームプラットフォーム

View Slide

157
申請が終わると、ゲームプラットフォームは「クライアントID」「クライアントシークレット」を発⾏します。ま
たゲーム開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。
ここではユーザーの情報を提供するAPIを利⽤したいので「profile」というサービスを申請しています。
ゲーム開発者
格ゲーX
クライアントID 利⽤サービス
abcdef profile

View Slide

158
Aさんは⾃分のスマホ内にインストールされている「格ゲーX」をやるためにユーザー認証をします。「格ゲーX」
は対戦記録を保存したりネット上のユーザーと対戦したりするため、ユーザー認証が必要なのです。
格ゲーX
abcdef profile
Aさんユーザー認証を要求

View Slide

159
格ゲーX内の埋め込みブラウザが起動して、ゲームプラットフォームの認証画⾯にリダイレクトされます。ちなみ
にインプリシットフローを使うので、response_typeはtokenです。
格ゲーX
abcdef profile
Aさん
https://gm.example.com/authorize.php?response_type=token&
client_id=abcdef&...
ID
パスワード
送信

View Slide

160
認証が完了すると、ゲームプラットフォームはアクセストークンを⽣成して、事前に登録したリダイレクトURIに
のハッシュフラグメントaccess_tokenに付与し、リダイレクトします。格ゲーXはそのリダイレクトURIのハッ
シュフラグメントからアクセストークンを取り出し、格ゲーXのデータベースに保存します。この時点で格ゲーX
はAさんのユーザーIDはわかりませんので、空⽩です。
格ゲーX
abcdef profile
Aさん https://kakugex/cb#access_token=sohg9ba&...
ユーザーID アクセストークン
sohg9ba
a-san sohg9ba

View Slide

161
先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。
格ゲーX
abcdef profile
Aさん
sohg9ba
hloq239f9k1
a-san sohg9ba

View Slide

162
プロファイル情報APIのレスポンスのJSONにuser_idというフィールドがあり、それがユーザーIDになります。
ユーザーIDはa-sanなので、格ゲーXにアクセスしてきたユーザーは、a-sanというユーザーIDの⼈であることが
わかりました。なので、格ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。これでa-san
が認証できたわけであり、これはOAuth認証になります。
格ゲーX
abcdef profile
Aさん
a-san sohg9ba
a-san sohg9ba
{
“user_id”: “a-san”,
“name”: “Aさん”,
…
}
ユーザー
情報

View Slide

163
次に、先程説明したOAuth認証によって、Aさんの情報が乗っ取られる流れをご説明しま
す。「悪いゲーム開発者」と「悪ゲーX」が増えました。
Aさん
格ゲーX
ゲーム開発者
格ゲーXをやる善良な市⺠です。
とあるゲームプラットフォームのも
とで開発された善良なスマホ⽤格闘
ゲームです。
格ゲーXを開発している善良な開発
者です。
ゲーム
プラットフォーム
ゲームを開発するためのプラットフ
ォームです。LINEとかが有名です。
悪ゲーX
悪いゲーム開発者
悪ゲーXを開発して、Aさんを乗っ取
ろうとする悪いやつです。
Aさんのユーザー情報を盗むための
専⽤のゲームです。

View Slide

164
まず悪ゲーXを開発するゲーム開発者は、ゲームプラットフォームに対して、OAuthで接続させてくださいみたい
な事前の申請を専⽤の申請フォームより⾏います。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、
ゲームプラットフォームに対して⾏いたい作業(閲覧や投稿)を申請します。この場合は、アクセスしてきたユー
ザーのプロファイル情報(ユーザー情報や名前など)を操作できる権限を申請します。
申請
悪ゲーX

View Slide

165
申請が終わると、ゲームプラットフォームは「クライアントID」「クライアントシークレット」を発⾏します。ま
たゲーム開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。
ここではユーザーの情報を提供するAPIを利⽤したいので「profile」というサービスを申請しています。
ghijklmn profile
悪ゲーX

View Slide

166
Aさんは「悪ゲーX」が、悪意のあるゲームであり、Aさんになりますことを企んでいるトンデモ野郎が開発した
ゲームであることを知りません。なので、Aさんは「悪ゲーX」にユーザー認証を要求します。
ghijklmn profile
Aさんユーザー認証を要求
悪ゲーX

View Slide

167
悪ゲーX内の埋め込みブラウザが起動して、ゲームプラットフォームの認証画⾯にリダイレクトされます。ちなみ
にインプリシットフローを使うので、response_typeはtokenです。
ghijklmn profile
Aさん
悪ゲーX
https://aku.example.com/authorize.php?response_type=token&
ID
パスワード
送信

View Slide

168
のハッシュフラグメントaccess_tokenに付与し、リダイレクトします。悪ゲーXはそのリダイレクトURIのハッ
シュフラグメントからアクセストークンを取り出し、悪ゲーXのデータベースに保存します。この時点で悪ゲーX
はAさんのユーザーIDはわかりませんので、空⽩です。
ghijklmn profile
Aさん
悪ゲーX
https://akugex/cb#access_token=hj98al0y&...
hj98al0y
a-san hj98al0y

View Slide

169
ghijklmn profile
Aさん
悪ゲーX
hj98al0y
a-san hj98al0y
hj98al0y アクセストークン

View Slide

170
わかりました。なので、悪ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。同時に悪ゲーX
は、Aさんのユーザー情報をクラウド上のデータベースに保存したとします。
ghijklmn profile
Aさん
悪ゲーX
a-san hj98al0y
a-san hj98al0y
{
…
}
ユーザー
情報
a-san hj98al0y
クラウド上のデータベース

View Slide

171
悪ゲーXからAさんのユーザー情報が書き込まれたクラウド上のデータベースの管理者はもちろん悪いゲーム開発
者です。なので、悪いゲーム開発者はAさんのアクセストークンを取得できます。
ghijklmn profile
Aさん
悪ゲーX
a-san hj98al0y
a-san hj98al0y
a-san hj98al0y
クラウド上のデータベース

View Slide

172
では、Aさんのアクセストークンを盗んだ悪いゲーム開発者がどのようにして、Aさんになりますかを⾒てみます。
悪いゲーム開発者は、「格ゲーX」をやるためにユーザー認証をします。
abcdef profile
ユーザー認証を要求
格ゲーX

View Slide

173
格ゲーX内の埋め込みブラウザが起動して、ゲームプラットフォームの認証画⾯にリダイレクトされます。
abcdef profile
格ゲーX
https://gm.example.com/authorize.php?response_type=token&
ID
パスワード
送信

View Slide

174
のハッシュフラグメントaccess_tokenに付与し、リダイレクトするのですが、ここで悪いゲーム開発者はリダイ
レクトURIのハッシュフラグメント中のアクセストークンを、先程盗んだAさんのアクセストークンに置き換えて
しまいます。置き換える⽅法はいくらでもあると思います。スマホの中にHTTPのリクエストをフックするツール
を⾃作して⼊れる⽅法も⼀つの⼿段です。
abcdef profile
格ゲーX
https://kakugex/cb#access_token=owj9hgoo&...
hj98al0y
aku owj9hgoo
hj98al0y
先程盗んだAさんアクセストークンに
置き換え

View Slide

175
abcdef profile
格ゲーX
hj98al0y
a-san hj98al0y
hj98al0y アクセストークン

View Slide

176
わかりました。なので、格ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。これでa-san
が認証できたわけであります。⾒事に悪いゲーム開発者はAさんになりすますことができました。
abcdef profile
格ゲーX
a-san hj98al0y
a-san hj98al0y
{
…
}
ユーザー
情報

View Slide

177
OAuth認証によるなりすましを防ぐには3つの⽅法があります。
アクセストークンの発⾏元を検証すること
認可コードフローを使うこと
OpenID Connectを使うこと

View Slide

178
1つ⽬の「アクセストークンの発⾏元を検証すること」という⽅法について説明します。アクセストークンを発⾏
する際に、アクセストークンの発⾏先のクライアントIDをゲームプラットフォーム(認可サーバー)の中に記録して
おきます。先程の例で⾔えば「悪ゲーX」のクライアントIDは「ghijklmn」なので、「悪ゲーX」向けに発⾏され
たアクセストークンは、以下のように発⾏先のクライアントIDを紐付けてデータベースに保存しておきます。
abcdef profile
格ゲーX
hj98al0y
ユーザーID アクセストークンクライアントID
a-san hj98al0y ghijklmn
悪ゲーXのクライアントID

View Slide

179
この状態で、「格ゲーX」からアクセストークンでリソースサーバーにリクエストを送るときに、ともにクライア
ントIDも送ってもらうよにして、アクセストークンをリクエストするクライアントのクライアントIDと、アクセ
ストークン発⾏先のクライアントIDが不⼀致であれば、不正であるとして、そのリクエストを破棄してしまえば、
Oauth認証を利⽤したなりすましは防ぐことができます。
abcdef profile
格ゲーX
hj98al0y
ユーザーID アクセストークンクライアントID
a-san hj98al0y ghijklmn
hj98al0y
abcdef
クライアントID 不⼀致

View Slide

180
残りの2つのうちの⼀つ「認可コードフローを使うこと」では、認可コードフローを使えばそもそ
もアクセストークンの置換ができないので成りすましはできず、OpenID Connectを利⽤すれば、
そもそもOpenID Connectはその仕様にアクセストークンの発⾏先を検証することが仕様として
定められているので成りすましを防げますが、本セミナーではその詳細は割愛します。
アクセストークンの発⾏元を検証すること
認可コードフローを使うこと
OpenID Connectを使うこと

View Slide

stateパラメーターによるCSRF対策
181

View Slide

stateパラメータによるCSRF対策
182
本章では、stateパラメーターによるCSRF対策を説明します。
stateパラメータとは︖
stateパラメーターは、CSRF(クロスサイトリクエストフォージェリ)対策で付与します。
CSRFとはユーザー本⼈が意図しないリクエストを、悪意のある第三者によって強制する攻
撃のことです。だいぶ昔には、mixiの「はまちちゃん」で有名になりましたが、OAuthや
OpenID Connectにも同様のリスクがあります。その対策がstateパラメーターになります。
ただ、stateパラメーターで対策するのは、「なりすまされ」というのであって、ここが今
までのCSRF対策とイマイチ違いがわかりにくい点になります。

View Slide

183
stateパラメーターのない世界と、ある世界ではどのように違うのかを説明することで、
stateパラメーターの有効性を説明します。とあるシステムを例に上げることとします。そ
のシステムの登場⼈物は以下のとおりとなります。
ストレージ
サービス
サービスA
クラウド上のオンラインストレージ
サービスです。ユーザーは⾃分の領
域に任意のファイルを格納すること
が出来ます。
ストレージサービスを利⽤するサー
ビスです。OAuth認証を⽤いて、
ユーザーにストレージサービスを利
⽤させます。
Aさん
サービスAの正規な利⽤者です。
悪い⼈
ユーザーAさんに対してCSRF攻撃
を⾏おうとする攻撃者です。

View Slide

184
stateパラメーターがない世界
stateパラメーターのない世界では、
どのような悪いことが起こるのかを
説明します。まず、以下のようなシ
ステムを想定します。ストレージ
サービスは外部にAPIを公開してお
り、そのAPIでファイルをアップ
ロードできます。そしてAPIの認証
はOAuthで⾏います。サービスAは
OAuth認証を⽤いて、ユーザーが
サービスAにアップロードした画像
をストレージサービスにもアップ
ロードします。悪い⼈は、まず、
サービスAにアクセスして、OAuth
連携を開始します。

View Slide

185
悪い⼈は、ストレージサービスの認
可画⾯にリダイレクトされます。
「はい」をクリックします。

View Slide

186
すると、認可コードをクエリパラ
メーターに付与した、サービスAへ
のリダイレクトが発⽣します。しか
し、悪い⼈は、ここで、リダイレク
ト先のURLだけ取得をし、サービス
Aにリダイレクトさせないようにし
ます。この実現⽅法は⾊々あります
が、独⾃のHTTPクライアントのプ
ログラムを開発して、Locationヘッ
ダからリダイレクト先のURLだけを
抜き取り、実際のリダイレクトはさ
せないようにすればよいと思います。

View Slide

187
悪い⼈は、先程取得したURLをメー
ルなどの⼿段でAさんに送付して、
AさんにそのURLにアクセスさせま
す。すると、アクセストークンを取
得する主体は、悪い⼈からAさんに
移り、悪い⼈のアクセストークンを
取得するプロセスは、今後、Aさん
のセッションで⾏われることとなり
ます。ここがキモです。

View Slide

188
サービスAは、認可コードをスト
レージサービスに渡して、アクセス
トークンを要求します。

View Slide

189
ストレージサービスは、悪い⼈のス
トレージにアクセスするためのアク
セストークンをサービスAに返しま
す。なぜそうなるかというと、アク
セストークンを取得するために発⾏
された認可コードは、悪い⼈によっ
て発⾏されたものだからです。
そして、そのアクセストークンは、
ユーザーAのデータベースに格納さ
れます。なぜそうなるかというと、
認可コードをサービスAに渡したの
は、他ならぬAさんだからです。

View Slide

190
つまり、Aさんは、悪い⼈のアクセ
ストークンを取得し、悪い⼈のスト
レージに⾃由にアクセスできるよう
になりました。他⼈のストレージを
⾃由にアクセスできるわけですから、
あまり害はないように思えますが、
ここで⼀番まずのは、Aさんが知ら
ない間にこのような状況に陥ってし
まったことです。これは、「乗っ取
り」ではなくて「乗っ取られ」とい
われるもので、例えば、他の⼈に漏
らしたくないような情報を⾃分の
フォルダにアップロードしたつもり
が、実は悪い⼈のフォルダに知らな
い間にアップロードしていることに
なり、悪い⼈はAさんのプライベー
トを⾒ることが出来てしまうわけで
す。

View Slide

191
stateパラメーターがある世界
stateパラメーターがあると、先程
のような被害を防ぐことが出来ます。
先程のケースで、stateパラメー
ターを付与した場合にどの様になる
かを説明してみます。
悪い⼈は、まず、サービスAにアク
セスして、OAuth連携を開始します。
ここまでは、先程と⼀緒です。

View Slide

192
悪い⼈は、ストレージサービスの認
可画⾯にリダイレクトされます。先
ほどと違うのは、サービスAがリダ
イレクト先のURLのパラメーターに
state=xyzという値を付与している
ことです。さらに、このとき、サー
ビスAは、このstateの値を悪い⼈の
セッションに紐づけます(Javaでい
えば、
request.getSession().setAttribute
(“state”,”xyz”)とします)。

View Slide

193
すると、認可コードをクエリパラ
メーターに付与した、サービスAへ
のリダイレクトが発⽣します。しか
し、悪い⼈は、ここで、リダイレク
ト先のURLだけ取得をし、サービス
Aにリダイレクトさせないようにし
ます。先ほどと違うのは、ストレー
ジサービスは、1つ前のプロセスで
渡されたstateパラメーターをその
まま同じように、リダイレクト先の
URLに付与しているところです。

View Slide

194
先程と同様に、悪い⼈は、先程取得
したURLをメールなどの⼿段でAさ
んに送付して、AさんにそのURLに
アクセスさせます。

View Slide

195
「stateパラメーターのない世界」
と決定的に違うのがこのプロセスで
す。サービスAは、URLに付与され
ているstateパラメーターと、アク
セスしてきたユーザーのセッション
に格納されているstateパラメー
ターを⽐較して、⼀致していなけれ
ば不正なアクセスとして、処理を中
断します。認可コードを取得したの
は悪い⼈なので、stateパラメー
ターは悪い⼈のセッションの中に格
納されていますが、認可コードをも
とにアクセストークンを要求したの
はAさんです。もちろん、Aさんの
セッションの中には、stateパラ
メーターの値が⼊っていないので、
下記のように不⼀致となります。こ
のような理路により、CSRF攻撃を
防御することが可能です。

View Slide

最後に︕︕
196
https://tech-lab.sios.jp/
弊社技術ブログで様々なお役⽴ち技術情報を
お届けしています︕︕

View Slide

最後に︕︕
197
多分わかりやすいOAuth
https://tech-lab.sios.jp/archives/8026
OAuthを実装してみました
OAuthやOpenID Connectで使われるstateパラメーターについて
「単なるOAUTH 2.0を認証に使うと、⾞が通れるほどのどでかいセキュリ
ティー・ホールができる」について
関連ブログ

View Slide

最後に︕︕
198
多分わかりやすいOpenID Connect
OpenID Connectで使われるnonceパラメーターについて
JSON Web Tokenによる認証
関連ブログ

View Slide

最後に︕︕
199
https://www.youtube.com/channel/UCjIVEOLmZlBrgq
7nrxVFuRw
YouTubeチャネルで様々なお役⽴ち技術情報を
お届けしています︕︕

View Slide

最後に︕︕
200
ご清聴ありがとう
ございました。

View Slide

世界一わかりみの深いOAuth入門 / wakarimioauth

世界一わかりみの深いOAuth入門 / wakarimioauth

Noriyuki TAKEI

More Decks by Noriyuki TAKEI

Other Decks in Technology

Featured

Transcript