$30 off During Our Annual Pro Sale. View Details »

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

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

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

Noriyuki TAKEI

May 13, 2021
Tweet

More Decks by Noriyuki TAKEI

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

  3. © 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

    View Slide

  4. © SIOS Technology, Inc. All rights Reserved.
    本セッションの概要
    4

    View Slide

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

    お届けします。

    View Slide

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

    View Slide

  7. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    7

    View Slide

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

    View Slide

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

    View Slide

  10. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    10
    よくわかりません。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    14
    ID・パスワード認証の場合

    View Slide

  15. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    15
    ID・パスワード認証の場合
    Aさん
    ユーザーID パスワード
    [email protected] password
    TwitterのシステムにAさん
    のFacebookのユーザーID。
    パスワードを登録します。

    View Slide

  16. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    16
    ID・パスワード認証の場合
    Aさんがつぶやき
    ます。
    Aさん
    ⽩⾦なう
    ユーザーID パスワード
    [email protected] password

    View Slide

  17. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    17
    ID・パスワード認証の場合
    Twitterのシステムに
    登録されている
    Facebookのユーザー
    ID・パスワードを元
    にFacebookに接続し
    ます。
    Aさん
    ユーザーIDとパスワー
    ドを送信
    ユーザーID パスワード
    [email protected] password

    View Slide

  18. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    18
    ID・パスワード認証の場合
    TwitterがユーザーA
    さんの代わりに
    Facebookに投稿しま
    す。
    Aさん
    ⽩⾦なう
    ユーザーID パスワード
    [email protected] password

    View Slide

  19. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    19
    ID・パスワード認証の場合
    Aさん
    悪い⼈
    投稿の削除、
    退会など
    ユーザーID パスワード
    [email protected] password

    View Slide

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

    View Slide

  21. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    21
    OAuthの場合

    View Slide

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

    View Slide

  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・シークレットの保存

    View Slide

  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

    View Slide

  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&...

    View Slide

  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
    認可画⾯の表⽰

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  33. © SIOS Technology, Inc. All rights Reserved.
    OAuthをざっくり説明
    33
    OAuthの場合
    再び悪い⼈の出番です。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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
    アクセストークンの取得
    ⼀致しているか確認
    こんな感じです。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. © SIOS Technology, Inc. All rights Reserved.
    OAuthの登場⼈物
    45

    View Slide

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

    View Slide

  47. © SIOS Technology, Inc. All rights Reserved.
    OAuthの登場⼈物
    47
    よくわかりません。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  53. © SIOS Technology, Inc. All rights Reserved.
    ⾊んなフロー
    53

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    ・ ・


    View Slide

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

    View Slide

  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&...

    View Slide

  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に紐づく
    処理を⾏います。

    View Slide

  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&...
    これがアクセストークン

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    ・ ・


    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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のパスワード
    [email protected] hogehoge
    リソースオーナーパスワードクレデンシャルズフロー

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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のパスワード
    [email protected] hogehoge
    バッチ処理サーバー
    Facebook
    Facebookのユーザー名 Facebookのパスワード
    [email protected] hogehoge
    OAuth適⽤前 OAuth適⽤後
    Facebookのユーザー名
    Facebookのパスワード

    View Slide

  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のパスワード
    [email protected] hogehoge
    バッチ処理サーバー
    (クライアント)
    Facebook
    (認可サーバー&リソースサーバー)
    Facebookのユーザー名 Facebookのパスワード
    [email protected] hogehoge
    OAuth適⽤前 OAuth適⽤後
    Facebookのユーザー名
    Facebookのパスワード

    View Slide

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

    View Slide

  88. © SIOS Technology, Inc. All rights Reserved.
    リフレッシュトークン
    88

    View Slide

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

    View Slide

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

    View Slide

  91. © SIOS Technology, Inc. All rights Reserved.
    リフレッシュトークン
    91
    よくわかりません。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    ⽩⾦なう

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  111. © SIOS Technology, Inc. All rights Reserved.
    アクセストークン
    111

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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 アクセストークン
    [email protected] hloq239f9k1
    TwitterのID アクセストークン
    [email protected] hloq239f9k1
    クライアントID クライアントシークレット 利⽤サービス
    abcde hgjeoob2592lrmo post,view
    hloq239f9k1
    ■ ⼿順その8
    アクセストークンの返却
    タイプA︓アクセストークンの中に情報を含まない場合

    View Slide

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

    View Slide

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

    View Slide

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

    認可サーバーとリソースサーバーが
    同じであれば、同じデータベースを
    共有するので、アクセストークンの
    正当性を確認するのも簡単だが、別
    れている場合は難しい。

    View Slide

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

    View Slide

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

    View Slide

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

    A

    View Slide

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

    View Slide

  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



    View Slide

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











    View Slide

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















    View Slide

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

    View Slide

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


































    A
    A
    A
    A



    View Slide

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

    )

    (


    )
    (
    )
    )
    )




    A
    1





    View Slide

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

    View Slide

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


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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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 アクセストークン
    [email protected] XXX.YYY.XXX
    クライアントID クライアントシークレット 利⽤サービス
    abcde hgjeoob2592lrmo post,view
    XXX.YYY.ZZZ
    ■ ⼿順その8
    アクセストークンの返却
    タイプB︓アクセストークンの中に情報を含む場合

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  153. © SIOS Technology, Inc. All rights Reserved.
    OAuthを認証に使うことの危険性
    153

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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さん”,

    }
    ユーザー
    情報

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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さんアクセストークンに
    置き換え

    View Slide

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

    View Slide

  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さん”,

    }
    ユーザー
    情報

    View Slide

  177. © SIOS Technology, Inc. All rights Reserved.
    OAuthを認証に使うことの危険性
    177
    OAuth認証によるなりすましを防ぐには3つの⽅法があります。
    アクセストークンの発⾏元を検証すること
    認可コードフローを使うこと
    OpenID Connectを使うこと

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  181. © SIOS Technology, Inc. All rights Reserved.
    stateパラメーターによるCSRF対策
    181

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  185. © SIOS Technology, Inc. All rights Reserved.
    stateパラメータによるCSRF対策
    185
    stateパラメーターがない世界
    悪い⼈は、ストレージサービスの認
    可画⾯にリダイレクトされます。
    「はい」をクリックします。

    View Slide

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

    View Slide

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

    View Slide

  188. © SIOS Technology, Inc. All rights Reserved.
    stateパラメータによるCSRF対策
    188
    stateパラメーターがない世界
    サービスAは、認可コードをスト
    レージサービスに渡して、アクセス
    トークンを要求します。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  194. © SIOS Technology, Inc. All rights Reserved.
    stateパラメータによるCSRF対策
    194
    stateパラメーターがある世界
    先程と同様に、悪い⼈は、先程取得
    したURLをメールなどの⼿段でAさ
    んに送付して、AさんにそのURLに
    アクセスさせます。

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  200. © SIOS Technology, Inc. All rights Reserved.
    最後に︕︕
    200
    ご清聴ありがとう
    ございました。

    View Slide