トークンの置き換えに注意！
こんばんはーです、ブログはやっぱり続かないなーって実感のくらです。
ここまで2回にわけてOAuth 2.0のAuthorization Code FlowとImplicit Flowの基礎をざっくりお話ししました。今回は「トークンの置き換え」についてお話ししたいと思います〜
トークンの置き換え攻撃って？
みなさんが毎日つかっているiPhoneやAndroidのアプリですが、アプリの目的には不要な情報の収集、IDやパスワード抜き盗りなど悪質なアプリがおおくなってきているらしいです。それらの中にはOAuthを悪用してトークンを置き換えて攻撃するアプリもでてきてしまっているようです。悪意をもった開発者が悪いアプリで取得したユーザさんのトークンを悪意のないアプリのアクセストークンと置き換えて認証をいつわっちゃったりするんです。そんなコトされたらこまっちゃいますよね。では、その方法がどんなものなのか簡単にみていきましょー
1. いつもどおりOAuth 2.0でリクエスト開始
具体例はいつものFacebookのウォールに投稿するアプリの例で説明します。
新しいアプリの利用を開始しました。これまでのアプリと同じようにOAuth 2.0プロトコルを用いたもののようです。認可サーバ（Authorization Server）にリクエストするとログインと認可を求められました。（なんだかあやしい気もするけどホントに大丈夫かな…？）
2. ログイン＆認可画面は公式だから大丈夫だよね…？
Facebookの公式のページでログイン＆認可を行います。「なーんだ。ちゃんとFacebookと連携しているので安心、安心。いつものように同意ボタン押せばいいんでしょ？」という感じでこのアプリに認可してアクセストークンをもらいます。
3. 悪意あるサーバにアクセストークンががが…
実はこのアプリはトークン置き換え攻撃を目的とした悪意あるアプリだったんです…ニャンてこったぁ！
4. 他のアプリのトークンと置き換えで認証されちゃう
悪意あるアプリに渡してしまったトークンは、他のImplicit Flowで実装したブラウザやスマフォアプリでも使用できるため、置き換えてユーザさんを装って認証されちゃうこともあるんです。アプリの開発者さんたちは、悪いひとたちが簡単にトークンを置き換えられないように実装する必要があるんですよ。
本日のまとめ
- OAuth 2.0を利用した悪意のあるアプリが増えてます
- アプリへの認可は慎重に！
- アクセストークンを盗まれるとなりすましされる可能性あり
- 開発者はトークンの流出だけでなく置き換えされにくい実装が必要
無料のアプリだからといって何も考えずに認可してトークンを盗まれてしまい、知らないところでつぶやきや画像が投稿されてしまうのは避けたいですよね。開発者さんたちも自分のアプリをとおして悪用されるのはこまるとおもいます。
このImplicit Flowのトークン置き換えの問題はOAuth 2.0をベースにした「OpenID Connect」というプロトコルで対策することができます。少し難しくなるのですが気になる人は以下を参考にするといいとおもいますー
このOpenID Connectについては機会があれば解説したいとおもいます。次回のテーマは決まっておらず、いつになるかわかりませんが気が向いたら書きたいと思います～
OAuth 2.0って知ってますかぁ？その2
おはようです、好きな調味料はマヨネーズのくらです。
前回の OAuth 2.0って知ってますかぁ？ではOAuth 2.0のサーバ側のアプリ用のプロトコルであるAuthorization Code Flowをお話しました。今回はその2ということで、エンドユーザさんのブラウザ側で実行されるアプリのタイプである「Implicit Flow」についてまとめますよ〜♪
Implicit Flowとは
Implicit FlowとはOAuth 2.0プロトコルのひとつなんです。サーバサイドで利用されるAuthorization Code Flowとちがって、Javascriptなどのスクリプト言語によってブラウザ上で実行されるアプリのフローになります。では、さっそくこの「Implicit Flow」について理解していきましょー！
1. やっぱりすぐにはAPIにアクセスできませんッ
また具体例としてFacebookのウォールに投稿するアプリでお話していきます。
はじめてこのアプリを利用としましょう。ウォールに書き込むためのAPIをつかおうとすると、ブラウザ上のJavascriptからFacebook側の認可サーバ（Authorization Server）にリクエストがおくられます。APIをつかうためにはやっぱり合鍵となるアクセストークン（Access Token）が必要なんですね。Implicit Flowでもすぐにはアクセストークンはもらえず、ユーザさんの認可をもとめられますッ
2. ログイン＆同意はお約束ごとッ
FacebookやTwitter連携のアプリにはお決まりになっているログインと同意をします。この認可の手順はOAuthのプロトコルではお約束なのでスキップはできないんですよ。同意をすると認可サーバからアクセストークンがもらえます…！？なんとImplicit FlowではAuthorization Code Flowにあった正しいサイトを確かめるための認可コードのやりとりがないんです！Implicitは「暗黙の」という意味のとおり同意のあと認可サーバはだまってアクセストークンをおくるんです。
フローが簡単になって便利だけど、認可コードによるサイトの確認をスキップしちゃっていいの？と思うかもしれません。でも大丈夫なんです。なぜなら、このフローはブラウザすなわちユーザさんと認可サーバで直接アクセストークンをやりとりするので、サイト側にアクセストークンをわたすことがないからなんです。きちんとブラウザ上のJavascriptなどのスクリプト言語で実行されるアプリであれば問題ないわけですねッ
3. トークンはブラウザ上で管理しますッ
おくられてきたアクセストークンはユーザさんの手元すなわちブラウザ上で管理することになります。必要に応じてJavascriptから保管してるアクセストークンをつかってAPIたたいて、ウォールに書き込みができるわけですッ
本日のまとめ
- Implicit FlowはJavascriptなどのスクリプト言語によるブラウザ上のアプリのフロー
- ユーザと認可サーバで直接アクセストークンのやりとりをするため、認可コードによるアプリ提供サイトの確認を省略
- アクセストークンはブラウザ上（ユーザ側）で管理
アクセストークンをブラウザで管理する方法ですが、例えばいまだとHTML5のWeb Storageでローカルに保存しておく方法などが利用できるとおもいます。でも、ユーザさん自身で管理しないといけないため、他の人にトークンをわたさないよう注意が必要ですよ！
これでようやくOAuth 2.0の基本は理解できましたね。次回はトークンの置き換えによるお話をしたいとおもいます〜☆
OAuth 2.0って知ってますかぁ？
おはようです、どちらかというと夜行性のくらです。
今月の 2/3 に行われたIdentity Conference #11で@ritouさんによるOpenID Connectのデモがありました。そこではImplicit FlowはRPの実装によってはセキュリティ的に危ないよ、というテーマでデモと議論がなされました。ボクも会場でお話を聞いていたのですが、知識不足もありその場では「ん？」って感じでしたので、後日@ritouさんや@konfooさんに詳しい解説をしていただき少しは理解できたと思うので、ボクのアタマの中身をまとめたいと思います〜
OpenID Connect？Implicit Flow？ってひともいると思うので、何回かにお話をわけてざっくりOAuth 2.0の基礎からみていきますねッ
Authorization Code Flowとは
まずImplicit Flowってのは、サービス間で認可情報の受け渡しを行うためのプロトコルであるOAuth 2.0のフローのひとつなんです。みなさんもよく使っているFacebookやTwitterのサードパーティアプリで「同意しますか？」ってきかれるあれですねぇ。2.0ってコトは1.0もあるの？っておもったりしますよね。もちろんありますッ。じゃあなにが違うの？とツッコミたくなるところですがお話がかなり遠回しになてしまうので、それはまたの機会にするとして、基本になるサーバサイドのアプリで利用される「Authorization Code Flow」についてまずは理解していきましょうー！
1. いきなりAPIにはアクセスできませんッ
細かいプロセスをはぶいておおまかな流れを説明しますね。具体例としてサーバサイドでFacebookのウォールに投稿をするアプリについてお話をします。
はじめてアプリを利用するとしましょう。ブラウザを起動してサイトaにアクセスします。ウォールに書き込むAPIをつかおうとすると、サイトaからFacebook側の認可サーバ（Authorization Server）にリクエストします。APIをつかうためにはその合鍵となるアクセストークン（Access Token）が必要になるのですが、すぐにはアクセストークンをもらうことはできません。認可サーバからユーザさんに同意をするようにもとめられるのです。
2. ログイン＆同意をするのですッ
ひらいているブラウザでFacebookにログインしていない場合はログインするようにうながされ、その後同意画面にうつります。サイトaの利用するAPIがどんな認可情報をもちいるのかユーザに確認するわけですね。問題なくユーザさんが同意すると今度は認可コード（Authorization Code）がサイトaにわたされます。この認可コードでサイトaがホンモノであるか確かめるのです。
3. 認可コードで証明しますッ
次にサイトaはうけとった認可コードといっしょにいくつかの情報を認可サーバにわたしてアクセストークンをリクエストします。この情報とは事前に登録されているサイトaのIDやパスワード（secret）などです。認可サーバは送られてきたコードや情報が正しいモノであるか確認して問題なければアクセストークンを発行してサイトaにわたします。これでようやく待ちに待ったアクセストークンが手に入るわけですね。
4. トークンはサーバ側であずかりますッ
送られてきたアクセストークンはサイトaであずかることになります。ユーザさんからのリクエストに応じてアクセストークンをつかってAPIをたたくことで、ウォールに投稿できるわけなんですよ。
本日のまとめ
- OAuthとはユーザが認可することでサービス間の情報の受け渡しを可能にするプロトコル
- Authorization Code Flowはサーバサイドのアプリのフロー
- 認可コードでホンモノか確認
- アクセストークンはアプリのサイト側で管理
ユーザさんはログインと同意ボタンをクリックするだけですが、実は目にみえないところでいろいろな処理がされていたんですよ。またアクセストークンはきちんとサイトaで管理されていれば、ユーザさん自信がめんどうをみてあげる必要がなくなるので安心です。
ざっくり説明するはずが長くなってしまいましたねぇ（汗）これで基本はなんとなく理解できたとおもいますので、次回はImplicit Flowについてお話したいとおもいます〜♪
ブログはじめましたぁ。
おはようございます、くらです。
知識の整理とまとめもかねてブログをはじめましたぁ。
IDPっぽいコトを中心に、個人的な感想とあわせてまじえてまとめていきます。
ボクの頭の中のまとめをイラストを入れながら簡単に解説できたらと思ってます。
三日坊主になりがちなので６割の力で続けていきたいとおもいますーw
よろしくお願いします〜♪
