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

by Noriyuki TAKEI

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© SIOS Technology, Inc. All rights Reserved. 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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 11 今回のセッションではこの4つの謎を⼀つづつ紐解いていきます。今回はこちらです。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ない認可コードフローやImplicitフローによりトークンを安全に取得トークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュアコレコレ

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 20 ID・パスワード認証の場合 Aさん悪い⼈投稿の削除、退会などユーザーID パスワード [email protected] password このしくみは、⼤きな弱点があります。TwitterにはAさんの FacebookのユーザーID・パスワードが登録されています。 Twitterを運営している⼈に悪い⼈がいて、その⼈がAさんの FacebookのID・パスワードで勝⼿にFacebookに接続できてしまいます。投稿の削除やアカウントの削除ができてしまいます。これを解決するのはOAuthです。OAuthは、 Twitter側にFacebookのユーザーID・パスワードを登録することなく、Facebookに認証します。

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 24 OAuthの場合ここからは、利⽤者であるAさんがTiwitter→Facebook連携を⾏います。まず、Aさんは、Twitterにアクセスして、 Tiwitter→Facebook連携の設定画⾯にアクセスします。 Aさん ■ ⼿順その3 TwitterにFacebook連携の要求クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view

Slide 25

Slide 25 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 25 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view すると、Aさんは、Facebookにリダイレクトされて、Facebookのログイン画⾯が表⽰されます。このリダイレクトの際、URLのクエリパラメータにclient_idを付与します。次の⼯程でこれを使います。 Facebookログイン ID パスワード送信 Aさん ■ ⼿順その4 Facebookログイン画⾯の表⽰ https://fb.example.com/authorize?responce_type=code&client_id=abcde&...

Slide 26

Slide 26 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 26 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ログインすると、Facebookは、Twitterと連携してもよいかどうかの確認画⾯を表⽰します。Facebookは、多分、いろんなサービスとの連携を許可していると思いますが、その多数あるサービスの中から、Twitterとの連携がOKかどうかの画⾯を表⽰できたのは、先程リダイレクトの際にクエリパラメータに渡されたクライアントIDから判断しています。 Aさん Twitterと連携してもいいですか︖ OK ■ ⼿順その5 認可画⾯の表⽰

Slide 27

Slide 27 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 27 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 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

Slide 28

Slide 28 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 28 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterはFacebookにアクセストークンを取得しに⾏きます。その際、先程発⾏された認可コードを渡します。 Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ■ ⼿順その7 アクセストークンの取得⼀致しているか確認

Slide 29

Slide 29 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 29 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可コードを要求されたFacebookは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したFacebook、アクセストークンを受け取った Twitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 ■ ⼿順その8 アクセストークンの返却

Slide 30

Slide 30 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 30 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさんは、Twitterにつぶやきます。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なう ■ ⼿順その9 Aさんのつぶやき

Slide 31

Slide 31 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 31 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう hloq239f9k1 ■ ⼿順その10 Facebookへの接続

Slide 32

Slide 32 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 32 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし⾒つかったら、それに紐づくユーザーIDで、Facebookに投稿します。これで、連携完了です。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう ■ ⼿順その11 連携完了︕︕

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 34 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitterを運営する⼈の中に悪い⼈がいたとします。その悪い⼈がAさんのアカウントを悪⽤してFacebookのアカウントを削除してやろうと考えました。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 悪い⼈

Slide 35

Slide 35 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 35 OAuthの場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view でもそんな事できません。せいぜい以下みたいに変なことをつぶやくくらいです。このアクセストークンには、「利⽤サービス」に登録されていること(この場合はpostとview)しかできないからです。そういう⾵にFacebook側で制御をかけているのです。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠いほげ Facebook A お腹すいた眠いほげ悪い⼈

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 38 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 ■ ⼿順その6 Tiwtterへのリダイレクト with 認可コード https://twitter.example.com/redirect?code=djlk9f2pkf さっき説明したOAuthのフローで認可コードを渡すところです。このあとこの認可コードをもとにアクセストークンを要求します。

Slide 39

Slide 39 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 39 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ■ ⼿順その7 アクセストークンの取得⼀致しているか確認こんな感じです。

Slide 40

Slide 40 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 40 ■ ⼿順その6 Tiwtterへのリダイレクト with アクセストークン認可コード経由で渡すのではなく、直接アクセストークンを渡してはどうでしょうか︖ クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view https://twitter.example.com/redirect?code=hloq239f9k1 Aさん

Slide 41

Slide 41 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 41 ■ ⼿順その6 Tiwtterへのリダイレクト with アクセストークン問題なさそうなのですが、アクセストークンが直接インターネットを流れるので、ハッカーがそれを奪う機会が多くなります。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view https://twitter.example.com/redirect?code=hloq239f9k1 Aさんスーパーハカー

Slide 42

Slide 42 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 42 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 ■ ⼿順その6 Tiwtterへのリダイレクト with 認可コード https://twitter.example.com/redirect?code=djlk9f2pkf じゃぁ認可コードでも同じじゃんって感じです。が、認可コードはアクセストークンにくらべて極端に短命です。OAuthの仕様では有効期限10分が推奨です。なので認可コードを奪われたとしても、あまりにも短命なので、それを使って悪いことしようとしたときには期限切れて使えないということになります。スーパーハカー

Slide 43

Slide 43 text

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 43 ということで今回の章では、以下の2つについて説明しました。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ないトークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュア認可コードフローやImplicitフローによりトークンを安全に取得コレコレ

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 48 先程紹介したOAuthの登場⼈物を「OAuthをざっくり説明」の図に当てはめてみます。これでイメージが湧くかと思います。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なうリソースオーナークライアント認可サーバー＆リソースサーバー

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

© SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 50 先程の図で認可サーバーとリソースサーバーが⼀緒になっていました。Facebookが認可もリソースの提供もやっていたのですが、実はこれが別々になるケースが最近はよくあります。その時の流れは以下の通りとなります。リソースオーナークライアント認可サーバー ① 認可リクエスト ID パスワード送信 ② ID・パスワード⼊⼒して認証 ③ クライントにリダイレクト with 認可コード認可コード認可コードアクセストークン ④ 認可コードでアクセストークンをリクエスト ⑤ アクセストークンを取得 ⑥ アクセストークンでリソースを取得リソースサーバーアクセストークン

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 54 今回は、アクセストークンを取得するためのいろんなフローについて説明します。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ないトークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュア認可コードフローやImplicitフローによりトークンを安全に取得コレ

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 56 認可コードフロー「OAuthをざっくり説明」のところで説明したフローが、認可コードフローになります。リソースオーナー認可サーバー＆リソースサーバー ① 認可リクエスト ID パスワード送信 ② ID・パスワード⼊⼒して認証 ③ クライントにリダイレクト with 認可コード認可コード認可コードアクセストークンアクセストークン ④ 認可コードでアクセストークンをリクエスト ⑤ アクセストークンを取得 ⑥ アクセストークンでリソースを取得「OAuthをざっくり説明」でいうところのAさん「OAuthをざっくり説明」でいうところのFacebook 「OAuthをざっくり説明」でいうところのTwitter

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 60 インプリシットフロークライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リソースオーナークライアント認可サーバー＆リソースサーバーちなみに認可コードフローの図を以下に再掲しますが、この場合は、リソースオーナー(Aさん)はクライアント(Twitter)の中にあるクライアントIDとクライアントシークレットにアクセスできません。これはTwitterのサーバーの中に保存されているためです。なので認可コードフローでは、クライアントIDとクライアントシークレットをクライアントの中に保存します。

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 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に紐づく処理を⾏います。

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 64 インプリシットフロースマホアプリ(クライアント)は、先程のリダイレクトURIを解析して、ハッシュフラグメントからアクセストークンを取得して、スマホアプリ内に保存します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ■ ⼿順その5 アクセストークンの取得と保存 FacebookのID アクセストークン [email protected] sohg9ba FacebookのID アクセストークン [email protected] sohg9ba

Slide 65

Slide 65 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 65 インプリシットフロースマホアプリ(クライアント)は、Facebook(リソースサーバー)にアクセストークンと送るとともに、投稿の⼀覧を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ■ ⼿順その6 Facebookへの接続 FacebookのID アクセストークン [email protected] sohg9ba sohg9ba

Slide 66

Slide 66 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 66 インプリシットフロースマホアプリ(クライアント)は、Facebook(リソースサーバー)にから投稿の⼀覧を受け取ります。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ■ ⼿順その7 結果の取得 FacebookのID アクセストークン [email protected] sohg9ba A お腹すいた眠い⽩⾦なう

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 70 クライアントクレデンシャルズフローバッチの開発者 (リソースオーナー) ■ ⼿順その3 アクセストークンの要求バッチ処理サーバー内のバッチプログラムは、クライアントIDとクライアントシークレットを渡して、アクセストークンを要求します。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレットクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view

Slide 71

Slide 71 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 71 クライアントクレデンシャルズフローバッチの開発者 (リソースオーナー) ■ ⼿順その3 アクセストークンの取得 Facebook(認可サーバー)は、クライアントIDとクライアントシークレットが正しいものであることが確認できたら、バッチ処理サーバー(クライアント)にアクセストークンを返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] sohg9ba FacebookのID アクセストークン [email protected] sohg9ba

Slide 72

Slide 72 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 72 クライアントクレデンシャルズフローバッチの開発者 (リソースオーナー) ■ ⼿順その4 アクセストークンでリソースの要求バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場合はFacebook投稿の⼀覧)を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] sohg9ba FacebookのID アクセストークン [email protected] sohg9ba ⼀致しているか確認

Slide 73

Slide 73 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 73 クライアントクレデンシャルズフローバッチの開発者 (リソースオーナー) ■ ⼿順その5 リソースの返却 Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアント)にFacebookの投稿⼀覧(リソース)を返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view A お腹すいた眠い⽩⾦なうリソース FacebookのID アクセストークン [email protected] sohg9ba FacebookのID アクセストークン [email protected] sohg9ba

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 75 今回は、以下の内容を説明しました。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ないトークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュア認可コードフローやImplicitフローによりトークンを安全に取得コレ

Slide 76

Slide 76 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 76 ここからはちょっと補⾜的なことを説明します。以下の図を覚えていますか︖クライアントクレデンシャルズフローで、クライアントシークレットは不特定多数のひとにばらまいてはいけないと説明しました。それはクライアントシークレットが強⼒な権限を持つからなのでが、それは先のクライアントクレデンシャルズフローで説明したように、クライアントクレデンシャルズフローではクライントIDとクライアントシークレットでアクセストークンを取得できます。なので権限が強⼒なのです。アプリの開発者クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ■ ⼿順その2 クライアントID・シークレットの保存クライアントID クライアントシークレット abcde hgjeoob2592lrmo クライアントID クライアントシークレット abcde hgjeoob2592lrmo ・・・・・・

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 81 バッチの開発者 (リソースオーナー) ■ ⼿順その3 アクセストークンの要求バッチ処理サーバー内のバッチプログラム(クライアント)は、Facebook(リソースサーバー)にリソースオーナーのユーザー名とパスワードを渡します。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Facebookのユーザー名 Facebookのパスワードリソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード [email protected] hogehoge

Slide 82

Slide 82 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 82 バッチの開発者 (リソースオーナー) ■ ⼿順その3 アクセストークンの取得 Facebook(認可サーバー)は、ユーザー名とパスワードが正しいものであることが確認できたら、バッチ処理サーバー(クライアント)にアクセストークンを返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン [email protected] sohg9ba リソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワードアクセストークン [email protected] hogehoge sohg9ba

Slide 83

Slide 83 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 83 バッチの開発者 (リソースオーナー) ■ ⼿順その4 アクセストークンでリソースの要求バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場合はFacebook投稿の⼀覧)を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン [email protected] sohg9ba ⼀致しているか確認 Facebookのユーザー名 Facebookのパスワードアクセストークン [email protected] hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー

Slide 84

Slide 84 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 84 バッチの開発者 (リソースオーナー) ■ ⼿順その5 リソースの返却 Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアント)にFacebookの投稿⼀覧(リソース)を返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view A お腹すいた眠い⽩⾦なうリソース FacebookのID アクセストークン [email protected] sohg9ba Facebookのユーザー名 Facebookのパスワードアクセストークン [email protected] hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー

Slide 85

Slide 85 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 85 このフローのメリットは、仮にOAuth適⽤前に基本認証(ユーザーIDとパスワードによる認証)を使っていて、OAuthに移⾏したとしても、バッチ処理サーバー(クライアント)がFacebookに渡す情報は変わらないということです。ということは、OAuthに変更下としても、バッチ処理サーバーのSDKのバージョンだけ上げれば、そのままFacebookに渡す情報を変えることなく OAuth対応できます。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Facebookのユーザー名 Facebookのパスワードリソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード [email protected] hogehoge バッチ処理サーバー Facebook Facebookのユーザー名 Facebookのパスワード [email protected] hogehoge OAuth適⽤前 OAuth適⽤後 Facebookのユーザー名 Facebookのパスワード

Slide 86

Slide 86 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 86 このフローのメリットは、仮にOAuth適⽤前に基本認証(ユーザーIDとパスワードによる認証)を使っていて、OAuthに移⾏したとしても、バッチ処理サーバー(クライアント)がFacebookに渡す情報は変わらないということです。ということは、OAuthに変更したとしても、バッチ処理サーバーのSDKのバージョンだけ上げれば、そのままFacebookに渡す情報を変えることなく OAuth対応できます。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Facebookのユーザー名 Facebookのパスワードリソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード [email protected] hogehoge バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) Facebookのユーザー名 Facebookのパスワード [email protected] hogehoge OAuth適⽤前 OAuth適⽤後 Facebookのユーザー名 Facebookのパスワード

Slide 87

Slide 87 text

© SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 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にした意味がないということなのかもしれません。

Slide 88

Slide 88 text

Slide 89

Slide 89 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 89 今回は、以下のポイントについて説明します。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ないトークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュア認可コードフローやImplicitフローによりトークンを安全に取得コレ

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Slide 92

Slide 92 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 92 では、ここでもリフレッシュトークンがない場合とリフレッシュトークンがある場合をくらべて、どんな点が良くなるのかを⽐較してみたいと思います。以下の図は、「OAuthをざっくり説明」で説明したもので、すでにアクセストークンを取得済みであることを表した図です。これをベースに説明します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なう ■ ⼿順その9 Aさんのつぶやき

Slide 93

Slide 93 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 93 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ではまず、リフレッシュトークンがない世界ではどのような不便なことがおこるのか説明します。AさんはTwitterに「⽩⾦なう」とつぶやきます。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なうリフレッシュトークンがない世界

Slide 94

Slide 94 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 94 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Twitter(クライアント)からFacebook(リソースサーバー)にアクセストークンが渡されて、TwitterはFacebookのAPIを実⾏することができて、TwitterのつぶやきがFacebookにも反映されます。リフレッシュトークンがない世界 Facebook A お腹すいた眠い⽩⾦なう hloq239f9k1

Slide 95

Slide 95 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 95 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view もう⼀度Twitterにつぶやいてみました。でも今度はアクセストークンの有効期限が切れてエラーになってしまいました。リフレッシュトークンがない世界 hloq239f9k1 ✗ ⽩⾦なう

Slide 96

Slide 96 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 96 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view しょうがないので、もう⼀度Facebook(認可サーバー)での認証からやり直してアクセストークンを取得するところからやり直そう。。。って事になります。でも、アクセストークンが切れるたびにこんな事するのめんどくさいですよね。なんとかしたいものです。リフレッシュトークンがない世界 Facebookログイン ID パスワード送信

Slide 97

Slide 97 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 97 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view そこでリフレッシュトークンがある世界です。実はFacebook(認可サーバー)での認証が終わって、Facebookからアクセストークンが発⾏されると同時にリフレッシュトークンも発⾏されます。 Aさん FacebookのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 hloq239f9k1 aq9vl02pf アクセストークンリフレッシュトークン

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 99 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンとリフレッシュトークンを取得した状態でTwitterにつぶやいてみます。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なうリフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf

Slide 100

Slide 100 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 100 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 通常通りTwitterにもFacebookにも反映されます。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう hloq239f9k1

Slide 101

Slide 101 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 101 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンの有効期限が切れてリクエストがエラーになってしまいました。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf hloq239f9k1 ✗

Slide 102

Slide 102 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 102 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter(クライアント)はリフレッシュトークンをFacebook(認可サーバー)に送ります。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン [email protected] hloq239f9k1 aq9vl02pf aq9vl02pf Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう

Slide 103

Slide 103 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 103 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンを受け取ったFacebook(認可サーバー)は、アクセストークンとリフレッシュトークンを再作成して、 Twitter(クライアント)に返します。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] uom2ch28 lkqo8mvnb TwitterのID アクセストークンリフレッシュトークン [email protected] uom2ch28 aq9vl02pf uom2ch28 lkqo8mvnb アクセストークンリフレッシュトークン

Slide 104

Slide 104 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 104 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 新しく⽣成されたアクセストークンで再度Facebook(リソースサーバー)にアクセスします。今度はちゃんと正常にアクセスできました︕︕ AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン [email protected] uom2ch28 lkqo8mvnb TwitterのID アクセストークンリフレッシュトークン [email protected] uom2ch28 aq9vl02pf uom2ch28 Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう

Slide 105

Slide 105 text

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 107 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) スーパーハカー盗聴アクセストークン(有効期限:6ヶ⽉) アクセストークンを盗んだハッカーは、⽤意にFacebookの情報を操作できてしまいます。有効期限が超⻑いからです。

Slide 108

Slide 108 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 108 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) スーパーハカー盗聴アクセストークン(有効期限:1時間) でもアクセストークンの有効期限を短くしておけば、たとえハッカーに盗まれたとしても1時間後には使えなくなるので、悪⽤されるリスクが減るわけです。 ✗期限切れ(><)

Slide 109

Slide 109 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 109 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) リフレッシュトークン(有効期限:6ヶ⽉) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) リフレッシュトークン(有効期限:6ヶ⽉) リフレッシュトークンもアクセストークンと同じくネットワーク上を流れます。そしてリフレッシュトークンはアクセストークンよりも有効期限は⻑いです。ただ、リフレッシュトークンはアクセストークンよりもネットワーク上を流れる頻度が少ないので、漏洩のリスクが少ないので、有効期限は⻑くても⽐較的⼤丈夫なのです。

Slide 110

Slide 110 text

© SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 110 今回は、以下のポイントについて説明しました。従来のID・パスワードベースとは異なるトークンベースの認証トークンには限られた権限だけを与えられているので、万が⼀トークンが盗まれても被害が少ないトークンには有効期限が設定されており、万が⼀トークンを盗まれても有効期限過ぎると使えないので、セキュア認可コードフローやImplicitフローによりトークンを安全に取得コレ

Slide 111

Slide 111 text

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 113 タイプA︓アクセストークンの中に情報を含まない場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view まずはタイプAのパターンについて説明します。ここで認可コードフローをちょっとおさらいします。認可コードフローでアクセストークンを取得するためには、認可コードをFacebook(認可サーバー)にリクエストしないとダメなのでした。なので、発⾏された認可コードを渡します。 Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ■ ⼿順その7 アクセストークンの取得⼀致しているか確認

Slide 114

Slide 114 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 114 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可コードを要求されたFacebookは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したFacebook、アクセストークンを受け取った Twitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 ■ ⼿順その8 アクセストークンの返却タイプA︓アクセストークンの中に情報を含まない場合

Slide 115

Slide 115 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 115 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさんは、Twitterにつぶやきます。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なう ■ ⼿順その9 AさんのつぶやきタイプA︓アクセストークンの中に情報を含まない場合

Slide 116

Slide 116 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 116 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう hloq239f9k1 ■ ⼿順その10 Facebookへの接続タイプA︓アクセストークンの中に情報を含まない場合

Slide 117

Slide 117 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 117 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし⾒つかったら、それに紐づくユーザーIDで、Facebookに投稿します。これで、連携完了です。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう ■ ⼿順その11 連携完了︕︕ タイプA︓アクセストークンの中に情報を含まない場合

Slide 118

Slide 118 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 118 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし⾒つかったら、それに紐づくユーザーIDで、Facebookに投稿します。これで、連携完了です。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう ■ ⼿順その11 連携完了︕︕ タイプA︓アクセストークンの中に情報を含まない場合

Slide 119

Slide 119 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 119 リソースオーナークライアント認可サーバー ① 認可リクエスト ID パスワード送信 ② ID・パスワード⼊⼒して認証 ③ クライントにリダイレクト with 認可コード認可コード認可コードアクセストークン ④ 認可コードでアクセストークンをリクエスト ⑤ アクセストークンを取得 ⑥ アクセストークンでリソースを取得リソースサーバーアクセストークンでは先程御説明したように認可サーバーとリソースサーバーが別々だった場合はどうでしょうか︖

Slide 120

Slide 120 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 120 タイプA︓アクセストークンの中に情報を含まない場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可サーバーとリソースサーバーが別々になった場合を考えてみます。以下は認可サーバーはマイクロソフトが提供するAzure Active Directory、リソースサーバーはFacebookという構成になります。この構成で、もう⼀度認可コードをリクエストするところから流れを追ってみたいと思います。なので、発⾏された認可コードを渡します。 Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ■ ⼿順その7 アクセストークンの取得⼀致しているか確認

Slide 121

Slide 121 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 121 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可コードを要求されたAzure Active Directoryは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したAzure Active Directory、アクセストークンを受け取ったTwitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。 Aさん FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 ■ ⼿順その8 アクセストークンの返却タイプA︓アクセストークンの中に情報を含まない場合

Slide 122

Slide 122 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 122 Aさん⽩⾦なう ■ ⼿順その9 AさんのつぶやきタイプA︓アクセストークンの中に情報を含まない場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさんは、Twitterにつぶやきます。

Slide 123

Slide 123 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 123 Aさん Twitter A お腹すいた眠い⽩⾦なう ■ ⼿順その10 Facebookへの接続タイプA︓アクセストークンの中に情報を含まない場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 アクセストークン TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。

Slide 124

Slide 124 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 124 Aさん Twitter A お腹すいた眠い⽩⾦なう ■ ⼿順その10 Facebookへの接続タイプA︓アクセストークンの中に情報を含まない場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン [email protected] hloq239f9k1 TwitterのID アクセストークン [email protected] hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 さて、ここからが問題なのですが、アクセストークンを受け取ったFacebook(リソースサーバー)はそのアクセストークンが正しいものかどうか確かめたいので、Azure Active Directory(認可サーバー)のアクセストークンと⽐較したいですが、通常 Azure Active DirectoryはFacebookとは全然異なるネットワークにあるため、直接データベースの中を⾒ることができません。 ✗ 認可サーバーとリソースサーバーが同じであれば、同じデータベースを共有するので、アクセストークンの正当性を確認するのも簡単だが、別れている場合は難しい。

Slide 125

Slide 125 text

Slide 126

Slide 126 text

Slide 127

Slide 127 text

Slide 128

Slide 128 text

Slide 129

Slide 129 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 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

Slide 130

Slide 130 text

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

Slide 137

Slide 137 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 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

Slide 138

Slide 138 text

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 140 JSON Web Tokenとは、以下のような形式です。 JSON Web Token eyJhb...(omit)...XVCJ9.e-KAnH ...(omit)... igJ19.977635 ...(omit)... ad ヘッダーペイロードヘッダーとペイロードをピリオドでつないで署名したものピリオドピリオド

Slide 141

Slide 141 text

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 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

Slide 144

Slide 144 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 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

Slide 145

Slide 145 text

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 147 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可コードを要求されたAzure Active Directoryは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、TwitterにJSON Web Token形式のアクセストークンを返します。タイプAと違うのは、Azure Active Directory側(認可サーバー)側にアクセストークンを保存していません。 Aさん TwitterのID アクセストークン [email protected] XXX.YYY.XXX クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view XXX.YYY.ZZZ ■ ⼿順その8 アクセストークンの返却タイプB︓アクセストークンの中に情報を含む場合

Slide 148

Slide 148 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 148 認可サーバー側でアクセストークンが作成される際、右図のような流れで作成されます。タイプB︓アクセストークンの中に情報を含む場合 { 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

Slide 149

Slide 149 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 149 Aさん⽩⾦なう ■ ⼿順その9 AさんのつぶやきタイプB︓アクセストークンの中に情報を含む場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterのID アクセストークン [email protected] XXX.YYY.XXX クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ということで、アクセストークンが無事作成されたので、まず、Aさんは、Twitterにつぶやきます。

Slide 150

Slide 150 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 150 Aさん Twitter A お腹すいた眠い⽩⾦なう ■ ⼿順その10 Facebookへの接続クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterのID アクセストークン [email protected] XXX.YYY.XXX クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view XXX.YYY.XXX アクセストークン TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。タイプB︓アクセストークンの中に情報を含む場合

Slide 151

Slide 151 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 151 アクセストークンを受け取った Facebook(リソースサーバー)は右図のような流れでアクセストークンが正しいかどうかを検証します。タイプB︓アクセストークンの中に情報を含む場合 { 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

Slide 152

Slide 152 text

© SIOS Technology, Inc. All rights Reserved. アクセストークン 152 Aさん Twitter A お腹すいた眠い⽩⾦なうクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterのID アクセストークン [email protected] XXX.YYY.XXX クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 無事連携完了できました。タイプAと異なり、Facebook(リソースサーバー)は、JSON Web Token形式のアクセストークンを検証することで、Facebookは、Azure Active Directoryなど他のシステムにアクセスすることなく、アクセストークンを検証することができました︕︕ タイプB︓アクセストークンの中に情報を含む場合 ■ ⼿順その11 連携完了︕︕ Facebook A お腹すいた眠い⽩⾦なう

Slide 153

Slide 153 text

Slide 154

Slide 154 text

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 158 Aさんは⾃分のスマホ内にインストールされている「格ゲーX」をやるためにユーザー認証をします。「格ゲーX」は対戦記録を保存したりネット上のユーザーと対戦したりするため、ユーザー認証が必要なのです。格ゲーX ゲームプラットフォームクライアントID 利⽤サービス abcdef profile Aさんユーザー認証を要求

Slide 159

Slide 159 text

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

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 161 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。格ゲーX ゲームプラットフォームクライアントID 利⽤サービス abcdef profile AさんユーザーID アクセストークン sohg9ba hloq239f9k1 ユーザーID アクセストークン a-san sohg9ba アクセストークン

Slide 162

Slide 162 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 162 プロファイル情報APIのレスポンスのJSONにuser_idというフィールドがあり、それがユーザーIDになります。ユーザーIDはa-sanなので、格ゲーXにアクセスしてきたユーザーは、a-sanというユーザーIDの⼈であることがわかりました。なので、格ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。これでa-san が認証できたわけであり、これはOAuth認証になります。格ゲーX ゲームプラットフォームクライアントID 利⽤サービス abcdef profile AさんユーザーID アクセストークン a-san sohg9ba ユーザーID アクセストークン a-san sohg9ba { “user_id”: “a-san”, “name”: “Aさん”, … } ユーザー情報

Slide 163

Slide 163 text

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

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 166 Aさんは「悪ゲーX」が、悪意のあるゲームであり、Aさんになりますことを企んでいるトンデモ野郎が開発したゲームであることを知りません。なので、Aさんは「悪ゲーX」にユーザー認証を要求します。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさんユーザー認証を要求悪ゲーX

Slide 167

Slide 167 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 167 悪ゲーX内の埋め込みブラウザが起動して、ゲームプラットフォームの認証画⾯にリダイレクトされます。ちなみにインプリシットフローを使うので、response_typeはtokenです。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX https://aku.example.com/authorize.php?response_type=token& client_id=abcdef&... ID パスワード送信

Slide 168

Slide 168 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 168 認証が完了すると、ゲームプラットフォームはアクセストークンを⽣成して、事前に登録したリダイレクトURIにのハッシュフラグメントaccess_tokenに付与し、リダイレクトします。悪ゲーXはそのリダイレクトURIのハッシュフラグメントからアクセストークンを取り出し、悪ゲーXのデータベースに保存します。この時点で悪ゲーX はAさんのユーザーIDはわかりませんので、空⽩です。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX https://akugex/cb#access_token=hj98al0y&... ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y

Slide 169

Slide 169 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 169 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン

Slide 170

Slide 170 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 170 プロファイル情報APIのレスポンスのJSONにuser_idというフィールドがあり、それがユーザーIDになります。ユーザーIDはa-sanなので、格ゲーXにアクセスしてきたユーザーは、a-sanというユーザーIDの⼈であることがわかりました。なので、悪ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。同時に悪ゲーX は、Aさんのユーザー情報をクラウド上のデータベースに保存したとします。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX ユーザーID アクセストークン a-san hj98al0y ユーザーID アクセストークン a-san hj98al0y { “user_id”: “a-san”, “name”: “Aさん”, … } ユーザー情報ユーザーID アクセストークン a-san hj98al0y クラウド上のデータベース

Slide 171

Slide 171 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 171 悪ゲーXからAさんのユーザー情報が書き込まれたクラウド上のデータベースの管理者はもちろん悪いゲーム開発者です。なので、悪いゲーム開発者はAさんのアクセストークンを取得できます。ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX ユーザーID アクセストークン a-san hj98al0y ユーザーID アクセストークン a-san hj98al0y ユーザーID アクセストークン a-san hj98al0y クラウド上のデータベース悪いゲーム開発者

Slide 172

Slide 172 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 172 では、Aさんのアクセストークンを盗んだ悪いゲーム開発者がどのようにして、Aさんになりますかを⾒てみます。悪いゲーム開発者は、「格ゲーX」をやるためにユーザー認証をします。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile ユーザー認証を要求悪いゲーム開発者格ゲーX

Slide 173

Slide 173 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 173 格ゲーX内の埋め込みブラウザが起動して、ゲームプラットフォームの認証画⾯にリダイレクトされます。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX https://gm.example.com/authorize.php?response_type=token& client_id=abcdef&... ID パスワード送信

Slide 174

Slide 174 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 174 認証が完了すると、ゲームプラットフォームはアクセストークンを⽣成して、事前に登録したリダイレクトURIにのハッシュフラグメントaccess_tokenに付与し、リダイレクトするのですが、ここで悪いゲーム開発者はリダイレクトURIのハッシュフラグメント中のアクセストークンを、先程盗んだAさんのアクセストークンに置き換えてしまいます。置き換える⽅法はいくらでもあると思います。スマホの中にHTTPのリクエストをフックするツールを⾃作して⼊れる⽅法も⼀つの⼿段です。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX https://kakugex/cb#access_token=owj9hgoo&... ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン aku owj9hgoo hj98al0y 先程盗んだAさんアクセストークンに置き換え

Slide 175

Slide 175 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 175 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン

Slide 176

Slide 176 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 176 プロファイル情報APIのレスポンスのJSONにuser_idというフィールドがあり、それがユーザーIDになります。ユーザーIDはa-sanなので、格ゲーXにアクセスしてきたユーザーは、a-sanというユーザーIDの⼈であることがわかりました。なので、格ゲーXのデータベースの中にユーザーIDをa-sanとして書き込みました。これでa-san が認証できたわけであります。⾒事に悪いゲーム開発者はAさんになりすますことができました。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX ユーザーID アクセストークン a-san hj98al0y ユーザーID アクセストークン a-san hj98al0y { “user_id”: “a-san”, “name”: “Aさん”, … } ユーザー情報

Slide 177

Slide 177 text

Slide 178

Slide 178 text

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

Slide 179

Slide 179 text

© SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 179 この状態で、「格ゲーX」からアクセストークンでリソースサーバーにリクエストを送るときに、ともにクライアントIDも送ってもらうよにして、アクセストークンをリクエストするクライアントのクライアントIDと、アクセストークン発⾏先のクライアントIDが不⼀致であれば、不正であるとして、そのリクエストを破棄してしまえば、 Oauth認証を利⽤したなりすましは防ぐことができます。ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークンクライアントID a-san hj98al0y ghijklmn hj98al0y アクセストークン abcdef クライアントID 不⼀致

Slide 180

Slide 180 text

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

Slide 181

Slide 181 text

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

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

Slide 185

Slide 185 text

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

© SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 187 stateパラメーターがない世界悪い⼈は、先程取得したURLをメールなどの⼿段でAさんに送付して、 AさんにそのURLにアクセスさせます。すると、アクセストークンを取得する主体は、悪い⼈からAさんに移り、悪い⼈のアクセストークンを取得するプロセスは、今後、Aさんのセッションで⾏われることとなります。ここがキモです。

Slide 188

Slide 188 text

Slide 189

Slide 189 text

© SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 189 stateパラメーターがない世界ストレージサービスは、悪い⼈のストレージにアクセスするためのアクセストークンをサービスAに返します。なぜそうなるかというと、アクセストークンを取得するために発⾏された認可コードは、悪い⼈によって発⾏されたものだからです。そして、そのアクセストークンは、ユーザーAのデータベースに格納されます。なぜそうなるかというと、認可コードをサービスAに渡したのは、他ならぬAさんだからです。

Slide 190

Slide 190 text

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

Slide 191

Slide 191 text

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

Slide 192

Slide 192 text

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

Slide 193

Slide 193 text

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

Slide 194

Slide 194 text

Slide 195

Slide 195 text

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

Slide 196

Slide 196 text

Slide 197

Slide 197 text

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

Slide 198

Slide 198 text

© SIOS Technology, Inc. All rights Reserved. 最後に︕︕ 198 多分わかりやすいOpenID Connect https://tech-lab.sios.jp/archives/8651 OpenID Connectで使われるnonceパラメーターについて https://tech-lab.sios.jp/archives/13087 JSON Web Tokenによる認証 https://tech-lab.sios.jp/archives/7576 関連ブログ