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

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

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

© 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

© SIOS Technology, Inc. All rights Reserved. 本セッションの概要 5 世界のどこよりもわかりみの深い
OAuth をお届けします。

© SIOS Technology, Inc. All rights Reserved. 本セッションの概要 6 ハッシュタグ
#siospslive もしくは @noriyukitakei に忌憚ないご意⾒お願いいたします

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 8 ところで
よく聞くけど OAuth ってなに︖

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

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

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

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 13 以下のユースケースを考えてみます。Twitterにつぶやくと、⾃動的にそのつ
ぶやきがFacebookにも反映される仕組みです。 Twitterにつぶやくと・・・ Facebookにも反映される⽩⾦なう⽩⾦なう Aさん

AさんユーザーID パスワード s-san@example.com password TwitterのシステムにAさんのFacebookのユーザーID。パスワードを登録します。

Aさんがつぶやきます。 Aさん⽩⾦なうユーザーID パスワード s-san@example.com password

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

TwitterがユーザーA さんの代わりに Facebookに投稿します。 Aさん⽩⾦なうユーザーID パスワード s-san@example.com password

Aさん悪い⼈投稿の削除、退会などユーザーID パスワード s-san@example.com password

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

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

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

ここからは、利⽤者であるAさんがTiwitter→Facebook連携を⾏います。まず、Aさんは、Twitterにアクセスして、 Tiwitter→Facebook連携の設定画⾯にアクセスします。 Aさん ▪ ⼿順その3 TwitterにFacebook連携の要求クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view

クライアント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&...

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

クライアント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

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterはFacebookにアクセストークンを取得しに⾏きます。その際、先程発⾏された認可コードを渡します。 Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ▪ ⼿順その7 アクセストークンの取得⼀致しているか確認

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 認可コードを要求されたFacebookは、⾃⾝が発⾏してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発⾏したFacebook、アクセストークンを受け取った Twitterの両⽅は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view hloq239f9k1 ▪ ⼿順その8 アクセストークンの返却

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさんは、Twitterにつぶやきます。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なう ▪ ⼿順その9 Aさんのつぶやき

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterはAさんのつぶやきを画⾯に表⽰します。それと同時に、Facebookにも同様の投稿を⾏います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう hloq239f9k1 ▪ ⼿順その10 Facebookへの接続

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし⾒つかったら、それに紐づくユーザーIDで、Facebookに投稿します。これで、連携完了です。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう ▪ ⼿順その11 連携完了︕︕

再び悪い⼈の出番です。

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitterを運営する⼈の中に悪い⼈がいたとします。その悪い⼈がAさんのアカウントを悪⽤してFacebookのアカウントを削除してやろうと考えました。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 悪い⼈

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view でもそんな事できません。せいぜい以下みたいに変なことをつぶやくくらいです。このアクセストークンには、「利⽤サービス」に登録されていること(この場合はpostとview)しかできないからです。そういう⾵にFacebook側で制御をかけているのです。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter A お腹すいた眠いほげ Facebook A お腹すいた眠いほげ悪い⼈

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 36 これがOAuthの最⼤のメリットです。ID・パスワー
ド認証をそのまま他のサービスに渡すと、どのように使われるかわかりません。OAuthのトークンであれば、被害を最⼩限に済ませることができます。

© SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 37 どうして認可コードを使うの︖⼿順が複雑になるし、
直接トークンを渡してくれればいいのに、、、。

© 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のフローで認可コードを渡すところです。このあとこの認可コードをもとにアクセストークンを要求します。

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん認可コード有効期限 djlk9f2pkf 2018年3⽉4⽇ 15:00 認可コード:djlk9f2pkf ▪ ⼿順その7 アクセストークンの取得⼀致しているか確認こんな感じです。

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

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

クライアントシークレット利⽤サービス 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分が推奨です。なので認可コードを奪われたとしても、あまりにも短命なので、それを使って悪いことしようとしたときには期限切れて使えないということになります。スーパーハカー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リソースオーナークライアント認可サーバー＆リソースサーバーちなみに認可コードフローの図を以下に再掲しますが、この場合は、リソースオーナー(Aさん)はクライアント(Twitter)の中にあるクライアントIDとクライアントシークレットにアクセスできません。これはTwitterのサーバーの中に保存されているためです。なので認可コードフローでは、クライアントIDとクライアントシークレットをクライアントの中に保存します。

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

ここでちょっとこの⼿順について追加の説明をします。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に紐づく処理を⾏います。

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

スマホアプリ(クライアント)は、先程のリダイレクトURIを解析して、ハッシュフラグメントからアクセストークンを取得して、スマホアプリ内に保存します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その5 アクセストークンの取得と保存 FacebookのID アクセストークン s-san@example.com sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba

スマホアプリ(クライアント)は、Facebook(リソースサーバー)にアクセストークンと送るとともに、投稿の⼀覧を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その6 Facebookへの接続 FacebookのID アクセストークン s-san@example.com sohg9ba sohg9ba

スマホアプリ(クライアント)は、Facebook(リソースサーバー)にから投稿の⼀覧を受け取ります。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その7 結果の取得 FacebookのID アクセストークン s-san@example.com sohg9ba A お腹すいた眠い⽩⾦なう

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

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

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

バッチの開発者 (リソースオーナー) ▪ ⼿順その3 アクセストークンの要求バッチ処理サーバー内のバッチプログラムは、クライアントIDとクライアントシークレットを渡して、アクセストークンを要求します。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレットクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view

バッチの開発者 (リソースオーナー) ▪ ⼿順その3 アクセストークンの取得 Facebook(認可サーバー)は、クライアントIDとクライアントシークレットが正しいものであることが確認できたら、バッチ処理サーバー(クライアント)にアクセストークンを返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン s-san@example.com sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba

バッチの開発者 (リソースオーナー) ▪ ⼿順その4 アクセストークンでリソースの要求バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場合はFacebook投稿の⼀覧)を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view FacebookのID アクセストークン s-san@example.com sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba ⼀致しているか確認

バッチの開発者 (リソースオーナー) ▪ ⼿順その5 リソースの返却 Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアント)にFacebookの投稿⼀覧(リソース)を返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view A お腹すいた眠い⽩⾦なうリソース FacebookのID アクセストークン s-san@example.com sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba

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

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

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

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

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

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

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

(リソースオーナー) ▪ ⼿順その3 アクセストークンの要求バッチ処理サーバー内のバッチプログラム(クライアント)は、Facebook(リソースサーバー)にリソースオーナーのユーザー名とパスワードを渡します。バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Facebookのユーザー名 Facebookのパスワードリソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード ntakei@example.com hogehoge

(リソースオーナー) ▪ ⼿順その3 アクセストークンの取得 Facebook(認可サーバー)は、ユーザー名とパスワードが正しいものであることが確認できたら、バッチ処理サーバー(クライアント)にアクセストークンを返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba リソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワードアクセストークン ntakei@example.com hogehoge sohg9ba

(リソースオーナー) ▪ ⼿順その4 アクセストークンでリソースの要求バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場合はFacebook投稿の⼀覧)を要求します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba ⼀致しているか確認 Facebookのユーザー名 Facebookのパスワードアクセストークン ntakei@example.com hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー

(リソースオーナー) ▪ ⼿順その5 リソースの返却 Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアント)にFacebookの投稿⼀覧(リソース)を返します。クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view A お腹すいた眠い⽩⾦なうリソース FacebookのID アクセストークン s-san@example.com sohg9ba Facebookのユーザー名 Facebookのパスワードアクセストークン ntakei@example.com hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー

© 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のパスワード ntakei@example.com hogehoge バッチ処理サーバー Facebook Facebookのユーザー名 Facebookのパスワード ntakei@example.com hogehoge OAuth適⽤前 OAuth適⽤後 Facebookのユーザー名 Facebookのパスワード

© 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のパスワード ntakei@example.com hogehoge バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) Facebookのユーザー名 Facebookのパスワード ntakei@example.com hogehoge OAuth適⽤前 OAuth適⽤後 Facebookのユーザー名 Facebookのパスワード

© 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にした意味がないということなのかもしれません。

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

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

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

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

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view もう⼀度Twitterにつぶやいてみました。でも今度はアクセストークンの有効期限が切れてエラーになってしまいました。リフレッシュトークンがない世界 hloq239f9k1 ✗ ⽩⾦なう

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

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view そこでリフレッシュトークンがある世界です。実はFacebook(認可サーバー)での認証が終わって、Facebookからアクセストークンが発⾏されると同時にリフレッシュトークンも発⾏されます。 Aさん FacebookのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 hloq239f9k1 aq9vl02pf アクセストークンリフレッシュトークン

© 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” }

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンとリフレッシュトークンを取得した状態でTwitterにつぶやいてみます。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なうリフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view 通常通りTwitterにもFacebookにも反映されます。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう hloq239f9k1

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view アクセストークンの有効期限が切れてリクエストがエラーになってしまいました。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf hloq239f9k1 ✗

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Twitter(クライアント)はリフレッシュトークンをFacebook(認可サーバー)に送ります。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf TwitterのID アクセストークンリフレッシュトークン s-san@example.com hloq239f9k1 aq9vl02pf aq9vl02pf Twitter A お腹すいた眠い⽩⾦なう Facebook A お腹すいた眠い⽩⾦なう

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンを受け取ったFacebook(認可サーバー)は、アクセストークンとリフレッシュトークンを再作成して、 Twitter(クライアント)に返します。 AさんクライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view リフレッシュトークンがある世界 FacebookのID アクセストークンリフレッシュトークン s-san@example.com uom2ch28 lkqo8mvnb TwitterのID アクセストークンリフレッシュトークン s-san@example.com uom2ch28 aq9vl02pf uom2ch28 lkqo8mvnb アクセストークンリフレッシュトークン

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

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

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

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

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

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

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

© 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 アクセストークンの取得⼀致しているか確認

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

クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view Aさんは、Twitterにつぶやきます。 Aさん FacebookのID アクセストークン s-san@example.com hloq239f9k1 TwitterのID アクセストークン s-san@example.com hloq239f9k1 クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ⽩⾦なう ▪ ⼿順その9 AさんのつぶやきタイプA︓アクセストークンの中に情報を含まない場合

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

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

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

© 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 アクセストークンの取得⼀致しているか確認

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

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

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

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

© SIOS Technology, Inc. All rights Reserved. アクセストークン 125 そこで
JSON Web Token です

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

© SIOS Technology, Inc. All rights Reserved. アクセストークン 127 お互いに同じ暗号化の鍵を共有して、暗号・複合する⽅式です。暗号化・復号化に使う鍵は同じです。鍵を相⼿に渡すときは、
盗聴されないよう、郵送などの⼿段を取る必要があります。秘密鍵暗号化⽅式 A

© SIOS Technology, Inc. All rights Reserved. アクセストークン 128 次に公開鍵暗号化⽅式です。
公開鍵暗号化⽅式公開鍵暗号化⽅式による改ざん防⽌公開鍵暗号化⽅式による⾝分証明秘密鍵暗号化⽅式コレ

© 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

© SIOS Technology, Inc. All rights Reserved. アクセストークン 130 秘密鍵暗号化⽅式だと、例えば下記例のようにAさんが、BさんとCさんとDさんに暗号化した⽂書を渡したい時に、郵送など絶
対に盗聴されない⼿段で、それぞれの⼈にAさんの秘密鍵を渡さないといけません。⾮常に⾯倒です。公開鍵暗号化⽅式

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

© SIOS Technology, Inc. All rights Reserved. アクセストークン 133 公開鍵暗号化⽅式を
使えば、暗号化した⽂書が通信経路の途中で改ざんされていないかどうかを検知することが可能です。公開鍵暗号化⽅式による改ざん防⽌ A A A A

© SIOS Technology, Inc. All rights Reserved. アクセストークン 134 改ざんされると以下
のような結果になり、改ざんされたことを検知できます。公開鍵暗号化⽅式による改ざん防⽌ ( ) ( ) ( ) ) ) A 1

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

© 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

© SIOS Technology, Inc. All rights Reserved. アクセストークン 138 いよいよ
JSON Web Tokenの説明になります。

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

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

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

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

© 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

© 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

クライアントシークレット利⽤サービス 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(リソースサーバー)の間で事前にアクセストークンを署名・検証するための共有鍵が管理者によって登録されているものとします。(実際は公開鍵暗号化⽅式でやっていると思うので、その必要はないと思いますが、説明を簡単にするため事前に共有鍵を交換するものとします)

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

© 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

⽩⾦なう ▪ ⼿順その9 AさんのつぶやきタイプB︓アクセストークンの中に情報を含む場合クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view TwitterのID アクセストークン s-san@example.com XXX.YYY.XXX クライアントID クライアントシークレット利⽤サービス abcde hgjeoob2592lrmo post,view ということで、アクセストークンが無事作成されたので、まず、Aさんは、Twitterにつぶやきます。

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

© 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

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

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

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

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

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

© 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 パスワード送信

© 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

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

© 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さん”, … } ユーザー情報

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

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

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

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

© 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 パスワード送信

のハッシュフラグメント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

ゲームプラットフォームクライアントID 利⽤サービス ghijklmn profile Aさん悪ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン

ユーザー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 クラウド上のデータベース

© 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 クラウド上のデータベース悪いゲーム開発者

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

© 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 パスワード送信

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

ゲームプラットフォームクライアントID 利⽤サービス abcdef profile 悪いゲーム開発者格ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン

ユーザー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さん”, … } ユーザー情報

© 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

© 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 不⼀致

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© 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 関連ブログ

© 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 関連ブログ

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

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

More Decks by Noriyuki TAKEI

Other Decks in Technology

Featured

Transcript