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

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

Transcript

1. © SIOS Technology, Inc. All rights Reserved. 世界⼀わかりみの深いOAuth⼊⾨ 〜認可の基礎から応⽤まで〜 武井 宜⾏ サイオステクノロジー株式会社 2021年5⽉14⽇
2. © SIOS Technology, Inc. All rights Reserved. ⽬次 2 序章︓ OAuthをざっくり説明 第２章︓⾊んなフロー 第３章︓ リフレッシュトークン 第４章︓アクセストークン 第５章︓OAuthを認証に使うことの危険性 第６章︓stateパラメータによるCSRF対策
3. © SIOS Technology, Inc. All rights Reserved. About Me 3 BCPVU
   NF Noriyuki TAKEI ෢Ҫ ٓߦ Information • サイオステクノロジー株式会社 • Microsoft MVP for Azure Favorites • Azure • Squash • Sweets blog https://tech-lab.sios.jp/ core skill Cloud Native, Serverless全般 Twitter @noriyukitakei
4. © SIOS Technology, Inc. All rights Reserved. 本セッションの概要 4
5. © SIOS Technology, Inc. All rights Reserved. 本セッションの概要 5 世界のどこよりもわかりみの深い OAuth を お届けします。
6. © SIOS Technology, Inc. All rights Reserved. 本セッションの概要 6 ハッシュタグ #siospslive もしくは @noriyukitakei に忌憚ないご意⾒ お願いいたします
7. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 7
8. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 8 ところで よく聞くけど OAuth ってなに︖
9. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 9 OAuthの特徴は以下のとおりです。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない 認可コードフローやImplicitフローにより トークンを安全に取得 トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア
10. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 10 よくわかりません。
11. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 11 今回のセッションではこの4つの謎を⼀つづつ紐解いていきます。今回はこち らです。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない 認可コードフローやImplicitフローにより トークンを安全に取得 トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア コレ コレ
12. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 12 新しいテクノロジーを理解しようとするときは、それに置き換わる従来のテ クノロジーとの⽐較をすると、分かりやすいです。ということで以下の②つ の認証⽅式を⽐較します。 ID・ パスワード 認証 従来のIDとパスワードによる認証です。Googleや Office365等の外部サービスのAPIの呼び出しに⻑いこと使 われてきました。 OAuth 今回の肝であるトークンベースのイカした認証⽅式です。 最近はもっぱらこれ。
13. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 13 以下のユースケースを考えてみます。Twitterにつぶやくと、⾃動的にそのつ ぶやきがFacebookにも反映される仕組みです。 Twitterにつぶや くと・・・ Facebookにも反 映される ⽩⾦なう ⽩⾦なう Aさん
14. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 14 ID・パスワード認証の場合
15. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 15 ID・パスワード認証の場合 Aさん ユーザーID パスワード s-san@example.com password TwitterのシステムにAさん のFacebookのユーザーID。 パスワードを登録します。
16. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 16 ID・パスワード認証の場合 Aさんがつぶやき ます。 Aさん ⽩⾦なう ユーザーID パスワード s-san@example.com password
17. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 17 ID・パスワード認証の場合 Twitterのシステムに 登録されている Facebookのユーザー ID・パスワードを元 にFacebookに接続し ます。 Aさん ユーザーIDとパスワー ドを送信 ユーザーID パスワード s-san@example.com password
18. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 18 ID・パスワード認証の場合 TwitterがユーザーA さんの代わりに Facebookに投稿しま す。 Aさん ⽩⾦なう ユーザーID パスワード s-san@example.com password
19. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 19 ID・パスワード認証の場合 Aさん 悪い⼈ 投稿の削除、 退会など ユーザーID パスワード s-san@example.com password
20. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 20 ID・パスワード認証の場合 Aさん 悪い⼈ 投稿の削除、 退会など ユーザーID パスワード s-san@example.com password このしくみは、⼤きな弱点があります。TwitterにはAさんの FacebookのユーザーID・パスワードが登録されています。 Twitterを運営している⼈に悪い⼈がいて、その⼈がAさんの FacebookのID・パスワードで勝⼿にFacebookに接続でき てしまいます。投稿の削除やアカウントの削除ができてしま います。これを解決するのはOAuthです。OAuthは、 Twitter側にFacebookのユーザーID・パスワードを登録する ことなく、Facebookに認証します。
21. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 21 OAuthの場合
22. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 22 OAuthの場合 Aさん Twitterシステム管理者 申請 ▪ ⼿順その1 Facebookへの申請 OAuthの認証の仕組みを説明します。まずTiwtterを運営するシステム管理者は、Facebookに対して、Oauthで接続 させてくださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が⽤意されてい ます。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投稿) を申請します。
23. © 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・シークレットの保存
24. © 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
25. © 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&...
26. © 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 認可画⾯の表⽰
27. © 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
28. © 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 アクセストークンの取得 ⼀致しているか確認
29. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 29 OAuthの場合 クライアント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 アクセストークンの返却
30. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 30 OAuthの場合 クライアント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さんのつぶやき
31. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 31 OAuthの場合 クライアント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への接続
32. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 32 OAuthの場合 クライアント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 連携完了︕︕
33. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 33 OAuthの場合 再び悪い⼈の出番です。
34. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 34 OAuthの場合 クライアント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 悪い⼈
35. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 35 OAuthの場合 クライアント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 お腹すいた 眠い ほげ 悪い⼈
36. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 36 これがOAuthの最⼤のメリットです。ID・パスワー ド認証をそのまま他のサービスに渡すと、どのよう に使われるかわかりません。OAuthのトークンであ れば、被害を最⼩限に済ませることができます。
37. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 37 どうして認可コードを使うの︖⼿順が複雑になるし、 直接トークンを渡してくれればいいのに、、、。
38. © 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のフローで認可コードを渡すところです。このあとこ の認可コードをもとにアクセストークンを要求します。
39. © 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 アクセストークンの取得 ⼀致しているか確認 こんな感じです。
40. © 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さん
41. © 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さん スーパー ハカー
42. © 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分が推奨です。なので認可コー ドを奪われたとしても、あまりにも短命なので、それを使って悪いことしようとしたと きには期限切れて使えないということになります。 スーパー ハカー
43. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 43 ということで今回の章では、以下の2つについて説明しました。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア 認可コードフローやImplicitフローにより トークンを安全に取得 コレ コレ
44. © SIOS Technology, Inc. All rights Reserved. OAuthをざっくり説明 44 ということで繰り返しになりますが、ID・パスワード認証をそのまま他の サービスに渡すと、どのように使われるかわからないのですが、OAuthの トークンであれば、被害を最⼩限に済ませることができます。これがOAuth を使うことの最⼤のメリットであり、これ以外の機能は極端に⾔うと、 OAuthの利⽤を補助するための機能でしかありません。なのでこの概念さえ しっかり抑えておけばOAuth怖くないです。私もOAuth知らないことばかり ですが、この概念をきっちり抑えたら、あとは仕様⾒て調べればいいやって ことになり苦⼿意識が消えました。
45. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 45
46. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 46 「OAuthをざっくり説明」のところでは、説明の都合上、⾊々はしょって書い てしまったので、改めてここで詳細を説明します。 リソースオーナーを認証し、アクセストークンを発⾏する サーバーです。 認可サーバー アクセストークンによる保護対象リソースを格納・提供す るサーバーです。 リソースサーバー リソースサーバーにアクセスして、アクセストークンを取 得するクライアントです。 クライアント リソースサーバーで提供されるリソースの持ち主です。 リソースオーナー
47. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 47 よくわかりません。
48. © 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 お腹すいた 眠い ⽩⾦なう リソースオーナー クライアント 認可サーバー＆リソースサーバー
49. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 49 ここからの説明の都合上、「OAuthをざっくり説明」で説明した流れを1枚のス ライドにまとめました。 リソース オーナー クライアント 認可サーバー＆ リソースサーバー ① 認可リクエスト ID パスワード 送信 ② ID・パスワード ⼊⼒して認証 ③ クライントにリダイレクト with 認可コード 認可 コード 認可 コード アクセス トークン アクセス トークン ④ 認可コードで アクセストークンを リクエスト ⑤ アクセストークン を取得 ⑥ アクセストークン でリソースを取得 「OAuthをざっくり説 明」でいうところのAさん 「OAuthをざっくり説明」 でいうところのFacebook 「OAuthをざっくり説明」 でいうところのTwitter
50. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 50 先程の図で認可サーバーとリソースサーバーが⼀緒になっていました。Facebookが認可も リソースの提供もやっていたのですが、実はこれが別々になるケースが最近はよくありま す。その時の流れは以下の通りとなります。 リソース オーナー クライアント 認可サーバー ① 認可リクエスト ID パスワード 送信 ② ID・パスワード ⼊⼒して認証 ③ クライントにリダイレクト with 認可コード 認可 コード 認可 コード アクセス トークン ④ 認可コードで アクセストークンを リクエスト ⑤ アクセストークン を取得 ⑥ アクセストークン でリソースを取得 リソースサーバー アクセス トークン
51. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 51 どうして認可サーバーとリソースサーバーが分かれることがあるのでしょうか︖それは、 最近「IDaaS」というのがはやっているからです。IDaaSの特徴は以下の通りとなります。 認証・認可のみに特化したSaaS型のマネージドサービス ワンタイムパスワードや証明書認証な 様々な認証⽅法を提供 Azure Active DirectoryやAuth0が有名
52. © SIOS Technology, Inc. All rights Reserved. OAuthの登場⼈物 52 例えば⾃社開発のオンラインストレージサービスを開始したいとします。でも、認証・認 可の機能を作り込むのは超⼤変です。そこをIDaaSに任せてしまえば、餅は餅屋というこ とで、認証・認可はIDaaSに任せて、⾃社のサービス開発に専念できます。 リソース オーナー クライアント Azure Active Directory ① 認可リクエスト ID パスワード 送信 ② ID・パスワード ⼊⼒して認証 ③ クライントにリダイレクト with 認可コード 認可 コード 認可 コード アクセス トークン ④ 認可コードで アクセストークンを リクエスト ⑤ アクセストークン を取得 ⑥ アクセストークン でリソースを取得 オンラインストレージ アクセス トークン ⾃社開発で 頑張る︕︕ アクセストークンを⽣成す る認可基盤はIDaaSである Azure Active Directoryに おまかせ︕︕
53. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 53
54. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 54 今回は、アクセストークンを取得するためのいろんなフローについて説明し ます。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア 認可コードフローやImplicitフローにより トークンを安全に取得 コレ
55. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 55 OAuthにはアクセストークンを取得するための3つの代表的なフローが存在し ます。 クライアントIDとクライアントシークレットを投げるとアクセストークン が返ってきます。主にバッチ処理向けフローです。 クライアント クレデンシャルズ フロー スマホアプリやブラウザ上のJava Scriptで動くネイティブアプリから直接 アクセストークンを発⾏する必要があるときのフローです。 ※ ただし現在は⾮推奨︕︕ インプリシット フロー 主にWebアプリケーション向けのフローで、認可コードフローをやり取り して、アクセストークンを取得します。 認可コードフロー
56. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 56 認可コードフロー 「OAuthをざっくり説明」のところで説明したフローが、認可コードフローになります。 リソース オーナー 認可サーバー＆ リソースサーバー ① 認可リクエスト ID パスワード 送信 ② ID・パスワード ⼊⼒して認証 ③ クライントにリダイレクト with 認可コード 認可 コード 認可 コード アクセス トークン アクセス トークン ④ 認可コードで アクセストークンを リクエスト ⑤ アクセストークン を取得 ⑥ アクセストークン でリソースを取得 「OAuthをざっくり説 明」でいうところのAさん 「OAuthをざっくり説明」 でいうところのFacebook 「OAuthをざっくり説明」 でいうところのTwitter
57. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 57 インプリシットフロー Aさん (リソースオーナー) アプリの開発者 申請 ▪ ⼿順その1 Facebookへの申請 インプリシットの流れを説明します。ここではAさん(リソースオーナー)内のスマホアプリ(クライアント)が、Facebook(リ ソースサーバー＆認可サーバー)の投稿⼀覧を取得するようなユースケースを考えてみます。まずアプリの開発者は、Facebook に対して、Oauthで接続させてくださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が ⽤意されています。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投 稿)を申請します。 Aさんのスマホ内のアプリ (クライアント) Facebook (認可サーバー＆リソースサーバー)
58. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 58 インプリシットフロー アプリの開発者 申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をアプリの開発者に発⾏します。またアプリ の開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。Facebookは、その クライアントID、クライアントシークレット、利⽤サービスを⾃⾝のデータベースに保存します。ここまででアプリの開発者の 仕事は終わりです。この作業はOAuth利⽤時にアプリの開発者が最初の⼀度だけ⾏えばよい作業です。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その2 クライアントID・シークレットの保存
59. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 59 インプリシットフロー アプリの開発者 ここでちょっとこの⼿順について追加の説明をします。インプリシットフローでは、クライアントID・クライアントシークレッ トは、クライアント(この場合だとスマホアプリ)に保存しません。なぜならば、インプリシットフローの場合は、クライアント であるスマホに、リソースオーナーが簡単にアクセスできます。つまりリソースオーナーがクライアントシークレットを取得で きます。もしクライアントID・クライアントシークレットをスマホに保存すると、クライアントID・クライアントシークレット はかなり強い権限を持っているので(詳細は後述)、複数のリソースオーナー(アプリ使う⼈)が強い権限を持ってしまうためです。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その2 クライアントID・シークレットの保存 クライアントID クライアントシークレット abcde hgjeoob2592lrmo クライアントID クライアントシークレット abcde hgjeoob2592lrmo ・ ・ ・ ・ ・ ・
60. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 60 インプリシットフロー クライアント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とクライアントシークレットをクライアントの中に保存します。
61. © 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&...
62. © 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に紐づく 処理を⾏います。
63. © 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&... これがアクセストークン
64. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 64 インプリシットフロー スマホアプリ(クライアント)は、先程のリダイレクトURIを解析して、ハッシュフラグメントからアクセストークンを取得して、 スマホアプリ内に保存します。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その5 アクセストークンの取得と保存 FacebookのID アクセストークン s-san@example.com sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba
65. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 65 インプリシットフロー スマホアプリ(クライアント)は、Facebook(リソースサーバー)にアクセストークンと送るとともに、投稿の⼀覧を要求します。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その6 Facebookへの接続 FacebookのID アクセストークン s-san@example.com sohg9ba sohg9ba
66. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 66 インプリシットフロー スマホアプリ(クライアント)は、Facebook(リソースサーバー)にから投稿の⼀覧を受け取ります。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その7 結果の取得 FacebookのID アクセストークン s-san@example.com sohg9ba A お腹すいた 眠い ⽩⾦なう
67. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 67 インプリシットフローのポイントは以下のとおりです。 認可コードフロートは異なり、認可サーバーへの認証完了の レスポンスで、ダイレクトにアクセストークンを受け取る アクセストークンがクライアント(スマホアプリ)⇔認可サーバー (Facebook)間を流れる、つまりパブリックなネットワーク上に流れるので、 漏洩のリスクが認可コードフローより⾼い。 インプリシットフローにはいくつかの脆弱性があり(後述)、今は⾮推奨。 スマホアプリのようなネイティブアプリでも認可コードフローを⽤いる。
68. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 68 クライアントクレデンシャルズフロー バッチの開発者 (リソースオーナー) 申請 ▪ ⼿順その1 Facebookへの申請 クライアントクレデンシャルズフローの流れを説明します。ここではバッチの開発者(リソースオーナー)が開発したバッチプロ グラムをバッチ処理サーバー(クライアント)に置いて、そのバッチプログラムからFacebook(認可サーバー＆リソースサーバー) の投稿⼀覧を取得するようなユースケースを考えてみます。まずバッチ開発者は、Facebookに対して、Oauthで接続させてく ださいみたいな事前の申請をします。これは、Facebookなどのサービスに申請専⽤の画⾯が⽤意されています。その申請 フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebookに対して⾏いたい作業(閲覧や投稿)を申請します。 バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー)
69. © 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
70. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 70 クライアントクレデンシャルズフロー バッチの開発者 (リソースオーナー) ▪ ⼿順その3 アクセストークンの要求 バッチ処理サーバー内のバッチプログラムは、クライアントIDとクライアントシークレットを渡して、アクセストークンを要求 します。 バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view クライアントID クライアントシークレット クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view
71. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 71 クライアントクレデンシャルズフロー バッチの開発者 (リソースオーナー) ▪ ⼿順その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
72. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 72 クライアントクレデンシャルズフロー バッチの開発者 (リソースオーナー) ▪ ⼿順その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 ⼀致しているか確認
73. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 73 クライアントクレデンシャルズフロー バッチの開発者 (リソースオーナー) ▪ ⼿順その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
74. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 74 クライアントクレデンシャルズフローのポイントは以下のとおりです。 クライアントIDとクライアントシークレットで アクセストークンを取得する。 クライアントIDとクライアントシークレットは強い権限を持つので 信頼できる相⼿にしか渡さない。この場合は、バッチの開発者地震 が管理しているサーバーなので問題はない。 バッチ処理のような場合、ブラウザが介在しないので、認可コードフローや インプリシットフローは当てはまらない。リソースーオーナーが信頼できる クライアントとリソースサーバーの間で⽤いる。
75. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 75 今回は、以下の内容を説明しました。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア 認可コードフローやImplicitフローにより トークンを安全に取得 コレ
76. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 76 ここからはちょっと補⾜的なことを説明します。以下の図を覚えていますか︖クライア ントクレデンシャルズフローで、クライアントシークレットは不特定多数のひとにばら まいてはいけないと説明しました。それはクライアントシークレットが強⼒な権限を持 つからなのでが、それは先のクライアントクレデンシャルズフローで説明したように、 クライアントクレデンシャルズフローではクライントIDとクライアントシークレットで アクセストークンを取得できます。なので権限が強⼒なのです。 アプリの開発者 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ▪ ⼿順その2 クライアントID・シークレットの保存 クライアントID クライアントシークレット abcde hgjeoob2592lrmo クライアントID クライアントシークレット abcde hgjeoob2592lrmo ・ ・ ・ ・ ・ ・
77. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 77 いろいろなフローをご説明しました。まずは最も利 ⽤頻度の⾼い(と思われる)認可コードフローを抑え ておけば⼤丈夫かと思います。他のフローは、認可 コードフローに⽑が⽣えたようなものですので。
78. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 78 おまけで リソースオーナーパスワードクレデンシャルズフロー というものを説明します。 基本は、クライアントクレデンシャルズフローと変わ りませんが、クライアントID・クライアントシーク レットの代わりにユーザー名とパスワードを渡します。
79. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 79 リソースオーナーパスワードクレデンシャルズフロー バッチの開発者 (リソースオーナー) 申請 ▪ ⼿順その1 Facebookへの申請 ここではバッチの開発者(リソースオーナー)が開発したバッチプログラムをバッチ処理サーバー(クライアント)に置いて、その バッチプログラムからFacebook(認可サーバー＆リソースサーバー)の投稿⼀覧を取得するようなユースケースを考えてみます。 まずバッチ開発者は、Facebookに対して、Oauthで接続させてくださいみたいな事前の申請をします。これは、Facebookなど のサービスに申請専⽤の画⾯が⽤意されています。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、Facebook に対して⾏いたい作業(閲覧や投稿)を申請します。 バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー)
80. © 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 リソースオーナーパスワードクレデンシャルズフロー
81. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 81 バッチの開発者 (リソースオーナー) ▪ ⼿順その3 アクセストークンの要求 バッチ処理サーバー内のバッチプログラム(クライアント)は、Facebook(リソースサーバー)にリソースオーナーのユーザー名と パスワードを渡します。 バッチ処理サーバー (クライアント) Facebook (認可サーバー＆リソースサーバー) クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view Facebookのユーザー名 Facebookのパスワード リソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード ntakei@example.com hogehoge
82. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 82 バッチの開発者 (リソースオーナー) ▪ ⼿順その3 アクセストークンの取得 Facebook(認可サーバー)は、ユーザー名とパスワードが正しいものであることが確認できたら、バッチ処理サーバー(クライア ント)にアクセストークンを返します。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba リソースオーナーパスワードクレデンシャルズフロー Facebookのユーザー名 Facebookのパスワード アクセストークン ntakei@example.com hogehoge sohg9ba
83. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 83 バッチの開発者 (リソースオーナー) ▪ ⼿順その4 アクセストークンでリソースの要求 バッチ処理サーバー(クライアント)は、Facebook(リソースサーバー)に対して、アクセストークンを送付してリソース(この場 合はFacebook投稿の⼀覧)を要求します。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view sohg9ba FacebookのID アクセストークン s-san@example.com sohg9ba ⼀致しているか確認 Facebookのユーザー名 Facebookのパスワード アクセストークン ntakei@example.com hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー
84. © SIOS Technology, Inc. All rights Reserved. ⾊んなフロー 84 バッチの開発者 (リソースオーナー) ▪ ⼿順その5 リソースの返却 Facebook(リソースサーバー)は、送付されたアクセストークンが正しいことを確認した上で、バッチ処理サーバー(クライアン ト)にFacebookの投稿⼀覧(リソース)を返します。 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view A お腹すいた 眠い ⽩⾦なう リソース FacebookのID アクセストークン s-san@example.com sohg9ba Facebookのユーザー名 Facebookのパスワード アクセストークン ntakei@example.com hogehoge sohg9ba リソースオーナーパスワードクレデンシャルズフロー
85. © 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のパスワード
86. © 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のパスワード
87. © 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にし た意味がないということなのかもしれません。
88. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 88
89. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 89 今回は、以下のポイントについて説明します。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア 認可コードフローやImplicitフローにより トークンを安全に取得 コレ
90. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 90 リフレッシュトークンの概要は以下のとおりです。 アクセストークンは超短命(1時間程度)であり、短命で あるがゆえに漏洩したときのリスクを抑えている。しか し、アクセストークンの有効期限を過ぎた場合に認可サ ーバーに再認証してもう⼀度アクセストークンを取得す るのは⾮常にユーザビリティに⽋けるため、リフレッシ ュトークンを認可サーバーに送るだけでアクセストーク ンを再取得できる。
91. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 91 よくわかりません。
92. © 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さんのつぶやき
93. © 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 ⽩⾦なう リフレッシュトークンがない世界
94. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 94 クライアント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 お腹すいた 眠い ⽩⾦なう Twitter(クライアント)からFacebook(リソースサーバー)にアクセストークンが渡されて、TwitterはFacebookのAPIを実⾏する ことができて、TwitterのつぶやきがFacebookにも反映されます。 リフレッシュトークンがない世界 Facebook A お腹すいた 眠い ⽩⾦なう hloq239f9k1
95. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 95 クライアント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につぶやいてみました。でも今度はアクセストークンの有効期限が切れてエラーになってしまいました。 リフレッシュトークンがない世界 hloq239f9k1 ✗ ⽩⾦なう
96. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 96 クライアント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 しょうがないので、もう⼀度Facebook(認可サーバー)での認証からやり直してアクセストークンを取得するところからやり直 そう。。。って事になります。でも、アクセストークンが切れるたびにこんな事するのめんどくさいですよね。なんとかしたい ものです。 リフレッシュトークンがない世界 Facebookログイン ID パスワード 送信
97. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 97 クライアント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 アクセストークン リフレッシュトークン
98. © 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” }
99. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 99 クライアントID クライアントシークレット 利⽤サービス 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
100. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 100 クライアントID クライアントシークレット 利⽤サービス 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
101. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 101 クライアントID クライアントシークレット 利⽤サービス 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 ✗
102. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 102 クライアントID クライアントシークレット 利⽤サービス 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 お腹すいた 眠い ⽩⾦なう
103. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 103 クライアントID クライアントシークレット 利⽤サービス 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 アクセストークン リフレッシュトークン
104. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 104 クライアントID クライアントシークレット 利⽤サービス 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 お腹すいた 眠い ⽩⾦なう
105. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 105 リフレッシュトークンなんてめんどくさい仕組み使 わずに、アクセストークンの有効期限をとても⻑く (例えば6ヶ⽉位とか)してしまえばいいのではない ですか︖
106. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 106 アクセストークンの有効期限を⻑くするのはNGです。アクセストークンはリソースサー バーにリクエストを送るたびにネットワーク上を流れます。ということはとても頻繁に ネットワークを流れることになり漏洩のリスクに晒されているのです。 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉)
107. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 107 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) アクセストークン(有効期限:6ヶ⽉) スーパーハカー 盗聴 アクセストークン(有効期限:6ヶ⽉) アクセストークンを盗んだハッカーは、⽤意にFacebookの情報を操作できてしまいます。 有効期限が超⻑いからです。
108. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 108 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) スーパーハカー 盗聴 アクセストークン(有効期限:1時間) でもアクセストークンの有効期限を短くしておけば、たとえハッカーに盗まれたとして も1時間後には使えなくなるので、悪⽤されるリスクが減るわけです。 ✗期限切れ(><)
109. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 109 Twitter (クライアント) Facebook (リソースサーバー) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) リフレッシュトークン(有効期限:6ヶ⽉) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) アクセストークン(有効期限:1時間) リフレッシュトークン(有効期限:6ヶ⽉) リフレッシュトークンもアクセストークンと同じくネットワーク上を流れます。そして リフレッシュトークンはアクセストークンよりも有効期限は⻑いです。ただ、リフレッ シュトークンはアクセストークンよりもネットワーク上を流れる頻度が少ないので、漏 洩のリスクが少ないので、有効期限は⻑くても⽐較的⼤丈夫なのです。
110. © SIOS Technology, Inc. All rights Reserved. リフレッシュトークン 110 今回は、以下のポイントについて説明しました。 従来のID・パスワードベースとは異なる トークンベースの認証 トークンには限られた権限だけを与えられているので、 万が⼀トークンが盗まれても被害が少ない トークンには有効期限が設定されており、万が⼀トークンを 盗まれても有効期限過ぎると使えないので、セキュア 認可コードフローやImplicitフローにより トークンを安全に取得 コレ
111. © SIOS Technology, Inc. All rights Reserved. アクセストークン 111
112. © SIOS Technology, Inc. All rights Reserved. アクセストークン 112 アクセストークンは、OAuthの仕様では、その形式を定めておりませんが、 主に以下の形式を取ります。 タイプA アクセストークンの中にアクセストークンに関する情報を 内包せず、やり取りされる情報はアクセストークンを⼀意 に識別する識別⼦のみで、アクセストークンに関する情報 はデータベースなどに保存する。 タイプB アクセストークンに関する情報をアクセストークンの中に 内包する形式
113. © 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 アクセストークンの取得 ⼀致しているか確認
114. © 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︓アクセストークンの中に情報を含まない場合
115. © SIOS Technology, Inc. All rights Reserved. アクセストークン 115 クライアント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さんのつぶやき タイプA︓アクセストークンの中に情報を含まない場合
116. © SIOS Technology, Inc. All rights Reserved. アクセストークン 116 クライアント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への接続 タイプA︓アクセストークンの中に情報を含まない場合
117. © SIOS Technology, Inc. All rights Reserved. アクセストークン 117 クライアント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 連携完了︕︕ タイプA︓アクセストークンの中に情報を含まない場合
118. © SIOS Technology, Inc. All rights Reserved. アクセストークン 118 クライアント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 連携完了︕︕ タイプA︓アクセストークンの中に情報を含まない場合
119. © SIOS Technology, Inc. All rights Reserved. アクセストークン 119 リソース オーナー クライアント 認可サーバー ① 認可リクエスト ID パスワード 送信 ② ID・パスワード ⼊⼒して認証 ③ クライントにリダイレクト with 認可コード 認可 コード 認可 コード アクセス トークン ④ 認可コードで アクセストークンを リクエスト ⑤ アクセストークン を取得 ⑥ アクセストークン でリソースを取得 リソースサーバー アクセス トークン では先程御説明したように認可サーバーとリソースサーバーが別々だった場合はどうで しょうか︖
120. © 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 アクセストークンの取得 ⼀致しているか確認
121. © SIOS Technology, Inc. All rights Reserved. アクセストークン 121 クライアントID クライアントシークレット 利⽤サービス 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︓アクセストークンの中に情報を含まない場合
122. © 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につぶやきます。
123. © SIOS Technology, Inc. All rights Reserved. アクセストークン 123 Aさん 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へのログインユーザーをキーにデータ ベースから取得します。
124. © SIOS Technology, Inc. All rights Reserved. アクセストークン 124 Aさん 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とは全然異なるネットワークにあるため、直接データベースの中を⾒ることができません。 ✗ 認可サーバーとリソースサーバーが 同じであれば、同じデータベースを 共有するので、アクセストークンの 正当性を確認するのも簡単だが、別 れている場合は難しい。
125. © SIOS Technology, Inc. All rights Reserved. アクセストークン 125 そこで JSON Web Token です
126. © SIOS Technology, Inc. All rights Reserved. アクセストークン 126 ちょっとJSON Web Tokenのことについて話す前に以下の前提知識が必要が ありますので、ちょっと横道にそれますが、お付き合いください。まずは秘 密鍵暗号化⽅式からです。 公開鍵暗号化⽅式 公開鍵暗号化⽅式による 改ざん防⽌ 公開鍵暗号化⽅式による ⾝分証明 秘密鍵暗号化⽅式 コレ
127. © SIOS Technology, Inc. All rights Reserved. アクセストークン 127 お互いに同じ暗号化の鍵を共有して、暗号・複合する⽅式です。暗号化・復号化に使う鍵は同じです。鍵を相⼿に渡すときは、 盗聴されないよう、郵送などの⼿段を取る必要があります。 秘密鍵暗号化⽅式 
     
     A 
128. © SIOS Technology, Inc. All rights Reserved. アクセストークン 128 次に公開鍵暗号化⽅式です。 公開鍵暗号化⽅式 公開鍵暗号化⽅式による 改ざん防⽌ 公開鍵暗号化⽅式による ⾝分証明 秘密鍵暗号化⽅式 コレ
129. © 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 
      
130. © SIOS Technology, Inc. All rights Reserved. アクセストークン 130 秘密鍵暗号化⽅式だと、例えば下記例のようにAさんが、BさんとCさんとDさんに暗号化した⽂書を渡したい時に、郵送など絶 対に盗聴されない⼿段で、それぞれの⼈にAさんの秘密鍵を渡さないといけません。⾮常に⾯倒です。 公開鍵暗号化⽅式   
      
        
        
        
       
131. © SIOS Technology, Inc. All rights Reserved. アクセストークン 131 公開鍵暗号化⽅式を使えば、インターネットなどで公開されているBさん、Cさん、Dさんの公開鍵を取得して、それで暗号化す ればOKです。公開鍵が通信経路で盗聴されたとしても、秘密鍵され漏洩しなければ、暗号化した⽂書は安全です。公開鍵暗号化 されたものは、秘密鍵でしか復号できないからです。 公開鍵暗号化⽅式
                          
132. © SIOS Technology, Inc. All rights Reserved. アクセストークン 132 次に公開鍵暗号化⽅式による改ざん防⽌です。 公開鍵暗号化⽅式 公開鍵暗号化⽅式による 改ざん防⽌ 公開鍵暗号化⽅式による ⾝分証明 秘密鍵暗号化⽅式 コレ
133. © SIOS Technology, Inc. All rights Reserved. アクセストークン 133 公開鍵暗号化⽅式を 使えば、暗号化した ⽂書が通信経路の途 中で改ざんされてい ないかどうかを検知 することが可能です。 公開鍵暗号化⽅式による改ざん防⽌
      
           
                   
       
          
        A A A A   
134. © SIOS Technology, Inc. All rights Reserved. アクセストークン 134 改ざんされると以下 のような結果になり、 改ざんされたことを 検知できます。 公開鍵暗号化⽅式による改ざん防⽌ ( 
      )  (   ) ( ) ) )   
        A 1     
135. © SIOS Technology, Inc. All rights Reserved. アクセストークン 135 次に公開鍵暗号化⽅式による⾝分証明です。 公開鍵暗号化⽅式 公開鍵暗号化⽅式による 改ざん防⽌ 公開鍵暗号化⽅式による ⾝分証明 秘密鍵暗号化⽅式 コレ
136. © SIOS Technology, Inc. All rights Reserved. アクセストークン 136 電⼦証明書を使えば、 インターネットの世 界で⾝分証明を⾏う ことが出来ます。リ アルな世界の印鑑証 明みたいなものです。 市役所に相当するの が認証局になります。 公開鍵暗号化⽅式による⾝分証明 S S   I ( ) S O( I ) S S S ) O)
137. © 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
138. © SIOS Technology, Inc. All rights Reserved. アクセストークン 138 いよいよ JSON Web Tokenの 説明になります。
139. © SIOS Technology, Inc. All rights Reserved. アクセストークン 139 まことにざっくりとした説明ですが、JSON Web Tokenの特徴は以下のとおりです。 JSON Web Token JSON Web Tokenとは、アクセストークンが正しいかどうかをチェックする仕 組みです。 JSON Web Tokenは、もっと専⾨的な⽤語を使いますと、JSONに電⼦署名を ⾏い、必要に応じてそのJSONの検証を⾏い、認証可否を決定する仕様です。 OpenIDやOAuthなどに⽤いられている標準的な仕様です。
140. © SIOS Technology, Inc. All rights Reserved. アクセストークン 140 JSON Web Tokenとは、以下のような形式です。 JSON Web Token eyJhb...(omit)...XVCJ9.e-KAnH ...(omit)... igJ19.977635 ...(omit)... ad ヘッダー ペイロード ヘッダーとペイロードを ピリオドでつないで署名 したもの ピリオド ピリオド
141. © SIOS Technology, Inc. All rights Reserved. アクセストークン 141 JSON Web Tokenのヘッダーは、以下のような形式です。 JSON Web Token { “alg”: ”HS256”, “typ”: “JWT” } 署名アルゴリズムで、 HS256であることを 表す。 トークンのタイプで JSON Web Tokenで あることを表す。
142. © SIOS Technology, Inc. All rights Reserved. アクセストークン 142 JSON Web Tokenのペイロードは、以下のような形式です。 例えばユーザー名だったり、認可情報だったり、ユーザーが⾃由 に定義します JSON Web Token { “sub”: “ntakei” } これは、ユーザー名がntakeiのデータになります。 ただ、何でも定義していいというわけではなく、幾 つかのフィールド名はJSON Web Tokenの仕様に よって予約されています。
143. © 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
144. © 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
145. © SIOS Technology, Inc. All rights Reserved. アクセストークン 145 横道にそれましたが 「タイプB︓アクセストークンの中に情報を含む場合」 の説明をしたいと思います。
146. © 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(リソースサーバー)の間 で事前にアクセストークンを署名・検証す るための共有鍵が管理者によって登録され ているものとします。(実際は公開鍵暗号 化⽅式でやっていると思うので、その必要 はないと思いますが、説明を簡単にするた め事前に共有鍵を交換するものとします)
147. © 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 アクセストークン s-san@example.com XXX.YYY.XXX クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view XXX.YYY.ZZZ ▪ ⼿順その8 アクセストークンの返却 タイプB︓アクセストークンの中に情報を含む場合
148. © 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
149. © SIOS Technology, Inc. All rights Reserved. アクセストークン 149 Aさん ⽩⾦なう ▪ ⼿順その9 Aさんのつぶやき タイプB︓アクセストークンの中に情報を含む場合 クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view TwitterのID アクセストークン s-san@example.com XXX.YYY.XXX クライアントID クライアントシークレット 利⽤サービス abcde hgjeoob2592lrmo post,view ということで、アクセストークンが無事作成されたので、まず、Aさんは、Twitterにつぶやきます。
150. © SIOS Technology, Inc. All rights Reserved. アクセストークン 150 Aさん 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︓アクセストークンの中に情報を含む場合
151. © 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
152. © SIOS Technology, Inc. All rights Reserved. アクセストークン 152 Aさん 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 お腹すいた 眠い ⽩⾦なう
153. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 153
154. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 154 本章では、OAuthを認証に使うことの危険性について説明したいと思います。 これはある特定の条件下で発⽣します。 インプリシットフローを使っている アクセストークンの発⾏元を検証していない プロファイル情報APIによって得たユーザー情報を 認証ユーザーとしている
155. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 155 では実際にやってみましょう。では通常のOAuth認証の流れについて説明し ます。登場⼈物は以下のとおりです。 Aさん 格ゲーX ゲーム開発者 格ゲーXをやる善良な市⺠です。 とあるゲームプラットフォームのも とで開発された善良なスマホ⽤格闘 ゲームです。 格ゲーXを開発している善良な開発 者です。 ゲーム プラットフォーム ゲームを開発するためのプラットフ ォームです。LINEとかが有名です。
156. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 156 まず格ゲーXを開発するゲーム開発者は、ゲームプラットフォームに対して、OAuthで接続させてくださいみたい な事前の申請を専⽤の申請フォームより⾏います。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、 ゲームプラットフォームに対して⾏いたい作業(閲覧や投稿)を申請します。この場合は、アクセスしてきたユー ザーのプロファイル情報(ユーザー情報や名前など)を操作できる権限を申請します。 ゲーム開発者 申請 格ゲーX ゲームプラットフォーム
157. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 157 申請が終わると、ゲームプラットフォームは「クライアントID」「クライアントシークレット」を発⾏します。ま たゲーム開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。 ここではユーザーの情報を提供するAPIを利⽤したいので「profile」というサービスを申請しています。 ゲーム開発者 格ゲーX ゲームプラットフォーム クライアントID 利⽤サービス abcdef profile
158. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 158 Aさんは⾃分のスマホ内にインストールされている「格ゲーX」をやるためにユーザー認証をします。「格ゲーX」 は対戦記録を保存したりネット上のユーザーと対戦したりするため、ユーザー認証が必要なのです。 格ゲーX ゲームプラットフォーム クライアントID 利⽤サービス abcdef profile Aさん ユーザー認証を要求
159. © 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 パスワード 送信
160. © 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
161. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 161 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。 格ゲーX ゲームプラットフォーム クライアントID 利⽤サービス abcdef profile Aさん ユーザーID アクセストークン sohg9ba hloq239f9k1 ユーザーID アクセストークン a-san sohg9ba アクセストークン
162. © 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さん”, … } ユーザー 情報
163. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 163 次に、先程説明したOAuth認証によって、Aさんの情報が乗っ取られる流れをご説明しま す。「悪いゲーム開発者」と「悪ゲーX」が増えました。 Aさん 格ゲーX ゲーム開発者 格ゲーXをやる善良な市⺠です。 とあるゲームプラットフォームのも とで開発された善良なスマホ⽤格闘 ゲームです。 格ゲーXを開発している善良な開発 者です。 ゲーム プラットフォーム ゲームを開発するためのプラットフ ォームです。LINEとかが有名です。 悪ゲーX 悪いゲーム開発者 悪ゲーXを開発して、Aさんを乗っ取 ろうとする悪いやつです。 Aさんのユーザー情報を盗むための 専⽤のゲームです。
164. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 164 まず悪ゲーXを開発するゲーム開発者は、ゲームプラットフォームに対して、OAuthで接続させてくださいみたい な事前の申請を専⽤の申請フォームより⾏います。その申請フォームに必要な項⽬を⼊⼒します。そのときに必ず、 ゲームプラットフォームに対して⾏いたい作業(閲覧や投稿)を申請します。この場合は、アクセスしてきたユー ザーのプロファイル情報(ユーザー情報や名前など)を操作できる権限を申請します。 悪いゲーム開発者 申請 悪ゲーX ゲームプラットフォーム
165. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 165 申請が終わると、ゲームプラットフォームは「クライアントID」「クライアントシークレット」を発⾏します。ま たゲーム開発者から申請があった作業(投稿や閲覧、以下利⽤サービスと呼びます)を独⾃の⽂字列に変換します。 ここではユーザーの情報を提供するAPIを利⽤したいので「profile」というサービスを申請しています。 ゲームプラットフォーム クライアントID 利⽤サービス ghijklmn profile 悪いゲーム開発者 悪ゲーX
166. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 166 Aさんは「悪ゲーX」が、悪意のあるゲームであり、Aさんになりますことを企んでいるトンデモ野郎が開発した ゲームであることを知りません。なので、Aさんは「悪ゲーX」にユーザー認証を要求します。 ゲームプラットフォーム クライアントID 利⽤サービス ghijklmn profile Aさん ユーザー認証を要求 悪ゲーX
167. © 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 パスワード 送信
168. © 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
169. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 169 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。 ゲームプラットフォーム クライアントID 利⽤サービス ghijklmn profile Aさん 悪ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン
170. © 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 クラウド上のデータベース
171. © 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 クラウド上のデータベース 悪いゲーム開発者
172. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 172 では、Aさんのアクセストークンを盗んだ悪いゲーム開発者がどのようにして、Aさんになりますかを⾒てみます。 悪いゲーム開発者は、 「格ゲーX」をやるためにユーザー認証をします。 ゲームプラットフォーム クライアントID 利⽤サービス abcdef profile ユーザー認証を要求 悪いゲーム開発者 格ゲーX
173. © 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 パスワード 送信
174. © 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さんアクセストークンに 置き換え
175. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 175 先程取得したアクセストークンを使って、ゲームプラットフォームのプロファイル情報APIにアクセスします。 ゲームプラットフォーム クライアントID 利⽤サービス abcdef profile 悪いゲーム開発者 格ゲーX ユーザーID アクセストークン hj98al0y ユーザーID アクセストークン a-san hj98al0y hj98al0y アクセストークン
176. © 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さん”, … } ユーザー 情報
177. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 177 OAuth認証によるなりすましを防ぐには3つの⽅法があります。 アクセストークンの発⾏元を検証すること 認可コードフローを使うこと OpenID Connectを使うこと
178. © 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
179. © 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 不⼀致
180. © SIOS Technology, Inc. All rights Reserved. OAuthを認証に使うことの危険性 180 残りの2つのうちの⼀つ「認可コードフローを使うこと」では、認可コードフローを使えばそもそ もアクセストークンの置換ができないので成りすましはできず、OpenID Connectを利⽤すれば、 そもそもOpenID Connectはその仕様にアクセストークンの発⾏先を検証することが仕様として 定められているので成りすましを防げますが、本セミナーではその詳細は割愛します。 アクセストークンの発⾏元を検証すること 認可コードフローを使うこと OpenID Connectを使うこと
181. © SIOS Technology, Inc. All rights Reserved. stateパラメーターによるCSRF対策 181
182. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 182 本章では、stateパラメーターによるCSRF対策を説明します。 stateパラメータとは︖ stateパラメーターは、CSRF(クロスサイトリクエストフォージェリ)対策で付与します。 CSRFとはユーザー本⼈が意図しないリクエストを、悪意のある第三者によって強制する攻 撃のことです。だいぶ昔には、mixiの「はまちちゃん」で有名になりましたが、OAuthや OpenID Connectにも同様のリスクがあります。その対策がstateパラメーターになります。 ただ、stateパラメーターで対策するのは、「なりすまされ」というのであって、ここが今 までのCSRF対策とイマイチ違いがわかりにくい点になります。
183. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 183 stateパラメーターのない世界と、ある世界ではどのように違うのかを説明することで、 stateパラメーターの有効性を説明します。とあるシステムを例に上げることとします。そ のシステムの登場⼈物は以下のとおりとなります。 ストレージ サービス サービスA クラウド上のオンラインストレージ サービスです。ユーザーは⾃分の領 域に任意のファイルを格納すること が出来ます。 ストレージサービスを利⽤するサー ビスです。OAuth認証を⽤いて、 ユーザーにストレージサービスを利 ⽤させます。 Aさん サービスAの正規な利⽤者です。 悪い⼈ ユーザーAさんに対してCSRF攻撃 を⾏おうとする攻撃者です。
184. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 184 stateパラメーターがない世界 stateパラメーターのない世界では、 どのような悪いことが起こるのかを 説明します。まず、以下のようなシ ステムを想定します。ストレージ サービスは外部にAPIを公開してお り、そのAPIでファイルをアップ ロードできます。そしてAPIの認証 はOAuthで⾏います。サービスAは OAuth認証を⽤いて、ユーザーが サービスAにアップロードした画像 をストレージサービスにもアップ ロードします。悪い⼈は、まず、 サービスAにアクセスして、OAuth 連携を開始します。
185. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 185 stateパラメーターがない世界 悪い⼈は、ストレージサービスの認 可画⾯にリダイレクトされます。 「はい」をクリックします。
186. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 186 stateパラメーターがない世界 すると、認可コードをクエリパラ メーターに付与した、サービスAへ のリダイレクトが発⽣します。しか し、悪い⼈は、ここで、リダイレク ト先のURLだけ取得をし、サービス Aにリダイレクトさせないようにし ます。この実現⽅法は⾊々あります が、独⾃のHTTPクライアントのプ ログラムを開発して、Locationヘッ ダからリダイレクト先のURLだけを 抜き取り、実際のリダイレクトはさ せないようにすればよいと思います。
187. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 187 stateパラメーターがない世界 悪い⼈は、先程取得したURLをメー ルなどの⼿段でAさんに送付して、 AさんにそのURLにアクセスさせま す。すると、アクセストークンを取 得する主体は、悪い⼈からAさんに 移り、悪い⼈のアクセストークンを 取得するプロセスは、今後、Aさん のセッションで⾏われることとなり ます。ここがキモです。
188. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 188 stateパラメーターがない世界 サービスAは、認可コードをスト レージサービスに渡して、アクセス トークンを要求します。
189. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 189 stateパラメーターがない世界 ストレージサービスは、悪い⼈のス トレージにアクセスするためのアク セストークンをサービスAに返しま す。なぜそうなるかというと、アク セストークンを取得するために発⾏ された認可コードは、悪い⼈によっ て発⾏されたものだからです。 そして、そのアクセストークンは、 ユーザーAのデータベースに格納さ れます。なぜそうなるかというと、 認可コードをサービスAに渡したの は、他ならぬAさんだからです。
190. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 190 stateパラメーターがない世界 つまり、Aさんは、悪い⼈のアクセ ストークンを取得し、悪い⼈のスト レージに⾃由にアクセスできるよう になりました。他⼈のストレージを ⾃由にアクセスできるわけですから、 あまり害はないように思えますが、 ここで⼀番まずのは、Aさんが知ら ない間にこのような状況に陥ってし まったことです。これは、「乗っ取 り」ではなくて「乗っ取られ」とい われるもので、例えば、他の⼈に漏 らしたくないような情報を⾃分の フォルダにアップロードしたつもり が、実は悪い⼈のフォルダに知らな い間にアップロードしていることに なり、悪い⼈はAさんのプライベー トを⾒ることが出来てしまうわけで す。
191. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 191 stateパラメーターがある世界 stateパラメーターがあると、先程 のような被害を防ぐことが出来ます。 先程のケースで、stateパラメー ターを付与した場合にどの様になる かを説明してみます。 悪い⼈は、まず、サービスAにアク セスして、OAuth連携を開始します。 ここまでは、先程と⼀緒です。
192. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 192 stateパラメーターがある世界 悪い⼈は、ストレージサービスの認 可画⾯にリダイレクトされます。先 ほどと違うのは、サービスAがリダ イレクト先のURLのパラメーターに state=xyzという値を付与している ことです。さらに、このとき、サー ビスAは、このstateの値を悪い⼈の セッションに紐づけます(Javaでい えば、 request.getSession().setAttribute (“state”,”xyz”)とします)。
193. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 193 stateパラメーターがある世界 すると、認可コードをクエリパラ メーターに付与した、サービスAへ のリダイレクトが発⽣します。しか し、悪い⼈は、ここで、リダイレク ト先のURLだけ取得をし、サービス Aにリダイレクトさせないようにし ます。先ほどと違うのは、ストレー ジサービスは、1つ前のプロセスで 渡されたstateパラメーターをその まま同じように、リダイレクト先の URLに付与しているところです。
194. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 194 stateパラメーターがある世界 先程と同様に、悪い⼈は、先程取得 したURLをメールなどの⼿段でAさ んに送付して、AさんにそのURLに アクセスさせます。
195. © SIOS Technology, Inc. All rights Reserved. stateパラメータによるCSRF対策 195 stateパラメーターがある世界 「stateパラメーターのない世界」 と決定的に違うのがこのプロセスで す。サービスAは、URLに付与され ているstateパラメーターと、アク セスしてきたユーザーのセッション に格納されているstateパラメー ターを⽐較して、⼀致していなけれ ば不正なアクセスとして、処理を中 断します。認可コードを取得したの は悪い⼈なので、stateパラメー ターは悪い⼈のセッションの中に格 納されていますが、認可コードをも とにアクセストークンを要求したの はAさんです。もちろん、Aさんの セッションの中には、stateパラ メーターの値が⼊っていないので、 下記のように不⼀致となります。こ のような理路により、CSRF攻撃を 防御することが可能です。
196. © SIOS Technology, Inc. All rights Reserved. 最後に︕︕ 196 https://tech-lab.sios.jp/ 弊社技術ブログで様々なお役⽴ち技術情報を お届けしています︕︕
197. © 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 関連ブログ
198. © 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 関連ブログ
199. © SIOS Technology, Inc. All rights Reserved. 最後に︕︕ 199 https://www.youtube.com/channel/UCjIVEOLmZlBrgq 7nrxVFuRw YouTubeチャネルで様々なお役⽴ち技術情報を お届けしています︕︕
200. © SIOS Technology, Inc. All rights Reserved. 最後に︕︕ 200 ご清聴ありがとう ございました。