明治大学の情報セキュリティ研究室が公開している「OAuthの仕組み丸分かり体験サイト」が話題になっているので、少し内容を見ていこうと思います。
※決してディスっている訳ではありません。敬遠されがちなOAuthなどの仕組みを簡易に解説しようとする取り組みは非常に大切だと思いますし、私も常に悩むポイントの一つです。
OAuthの仕組み丸分かり体験サイト
https://www.saitolab.org/oauth/
尚、最初の公開後、かなり修正が入っていて誤解を招く部分はかなり減っており、投稿するのをやめようかと思ったのですが、逆に課題認識の部分がぼやけてしまったところもあるので、あえて投稿してみます。
中身ですが、元々は所謂OAuth認証問題です。一番残念なところはFacebookをOAuthの利用例に挙げてしまったところです。公開当初はユーザがIDやパスワードを覚えなくても良くなるので、OAuthでFacebook上のアイデンティティ情報を引っ張ってくれば認証の代わりに出来るのでとっても便利！という文脈でした。（現在はソーシャルログインはオマケ的な紹介にとどまっています）
[OAuth認証問題]
簡単に言うと、アクセストークンなどのBearerトークン（本来の持ち主かどうかは関係なく、持参した人に対して認可をするもの。合鍵ですね）を使ってユーザ認証をしてしまう問題。その名のとおり本来の持ち主以外でもトークンを持ってくることが出来てしまうので認証として使うのは危ない、という話です。
詳しくは崎村さんのblogを。
http://www.sakimura.org/2012/02/1487/
http://www.sakimura.org/2011/05/1087/
Bearerトークンについてはこちら。
http://idmlab.eidentity.jp/2013/09/bearer-token.html
全体を通して軽く読み流した感想としては「なぜOAuthの話なのにfacebookログインをユースケースとして選んじゃったのかな・・・」というのが正直なところです。ログインじゃなくて、Graph APIでタイムラインを引っ張ってくるくらいの方が本来のOAuthの目的である「認可」を理解してもらうには適していると思うのですが。
（もしくは写真共有などのサイトを例にした方がわかりやすかったと思います）
結局のところ、根底には「認証」とか「認可」とかというキーワードが「アイデンティティ」と「なんとなく」関係があるのかな？というもやっとした共通認識が根底にあるような気がしてなりません。
現在はオマケとして紹介されているソーシャルログインの部分にも書かれている、Facebookで認証されたブラウザ「だけ」が認可コードをクライアントに渡すことが出来る、ことを前提とした認証は、ユーザの認証になっていない点が大きな問題点です。
（注意点として認可コードの置き換えに関して記載がありますが）
例えば、「ナンバープレート」だけを見て「運転者が車の持ち主である」と決めつけることが出来ないのと同じ理屈だと思います。駐車禁止の罰金もナンバープレートだけでは特定できないことから減点ではなく罰金だけに変わりましたよね？
以下、引用です。
免許証作成サイトにとって，「OAuth認証」が成立するための前提は以下となります：
Facebookがきちんと「あなた」本人であることを確認（＝認証）していて，Facebook上で「あなた」がプロフィール情報（名前と写真）を利用する「許可証（＝認証コード）」を発行できること
最初にアクセスしたブラウザと「許可証（＝認可コード）」を提示したブラウザが同じであること（これはクッキーを利用します）
「許可証（＝認可コード）」は有効期限内あること
最初に「許可証（＝認可コード）」を提示したら，Facebook上で認証された「あなた」以外は「許可証（＝認可コード）」を提示できないので，登録後に同じものを提示できるのは「あなた」だけであると判断できます．これは，最初の登録後，「許可証（＝認可コード）」を次回以降の接続時に提示できることにより，本人性の確認を実現しています．いわゆる，TOFU (Trust On First Use) と呼ばれる仕組みです．
しかしながら，OAuth認証における「許可証（＝認可コード）」は，通信路が無防備なので，「許可証（＝認可コード）」が盗まれたり，書き換えられたり，でっち上げられたりしてしまいます．OAuth認証は，安全性より，手軽さを優先する実現と言えるでしょう．
では、どうすれば良かったのか、について個人的な意見を。
＜課題の設定＞
現在は免許証サイトへ個人情報（名前など）を入力するのが面倒くさい、というのが課題として挙げられており、そのためにOAuthを使ってFacebookから情報をとってくる、というのが解決策として挙げられています。
しかし、本来は、
・リソースオーナーの所有しているデータへ
・クライアント（今回でいうところの免許証サイト）が
・リソースオーナーの望んだ範囲（スコープ）で同意の上で
・クライアントにリソースオーナーのIDやパスワードを伝えることなく
・アクセスされることが出来るか？
というのが一番の関心事であるはずです。
Japan Web API Communityのプレゼン資料より
https://www.slideshare.net/naohiro.fujie/oauth20web-api
＜取り上げるべきポイント＞
上記の課題をOAuthがどうやって解決していくのか？を中心に解説し体験してもらえるようにすればより理解が進むはずなので、アクターの整理をまずはすべきだと思います。
その上で、
・リソースオーナーが望んだ範囲（スコープ）の定義の仕方
・同意の取り方
・クライアントへリソースオーナーのID/パスワードを登録する必要がないこと
を解説することで理解が進むと思います。
全てを解説はしていませんが、こんな感じです。
他にも認可コードの置き換えの可能性について記載するのであればPKCEについても解説してもらった方がOAuthを使う開発者が安全性を気にする一つのきっかけになったかも知れません。
PKCEについてはこちらから。
OAuth PKCEがRFC7636として発行されました
https://www.sakimura.org/2015/09/3206/
＜OAuthとアイデンティティの関係＞
結局はOAuthとアイデンティティは直接関係はなく、アイデンティティをOAuthの仕組みを使って上手にやり取りしたのがOpenID Connectです。当該のサイトの主旨とはズレてしまいますが、ソーシャルログインや認証の話を取り上げるのであればOpenID Connectの話を本来は取り上げても良かったのかな？とも思います。
このあたりです。
アイデンティティ、認証＋OAuth＝OpenID Connect
http://www.sakimura.org/2013/07/2048/
冒頭にも書きましたが、利用が進んでいる割に汎用的であるが故に本来の目的からズレた使い方がされてしまいがちなOAuthですが、上手に使えば便利で安全な仕組みなのできちんと理解をして使っていきたいですね。
0 件のコメント:
コメントを投稿