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とは

f:id:kura_lab:20120228012621p:plain

まず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）が必要になるのですが、すぐにはアクセストークンをもらうことはできません。認可サーバからユーザさんに同意をするようにもとめられるのです。

f:id:kura_lab:20120227235524p:plain

2. ログイン＆同意をするのですッ

ひらいているブラウザでFacebookにログインしていない場合はログインするようにうながされ、その後同意画面にうつります。サイトaの利用するAPIがどんな認可情報をもちいるのかユーザに確認するわけですね。問題なくユーザさんが同意すると今度は認可コード（Authorization Code）がサイトaにわたされます。この認可コードでサイトaがホンモノであるか確かめるのです。

f:id:kura_lab:20120228010540p:plain

3. 認可コードで証明しますッ

次にサイトaはうけとった認可コードといっしょにいくつかの情報を認可サーバにわたしてアクセストークンをリクエストします。この情報とは事前に登録されているサイトaのIDやパスワード（secret）などです。認可サーバは送られてきたコードや情報が正しいモノであるか確認して問題なければアクセストークンを発行してサイトaにわたします。これでようやく待ちに待ったアクセストークンが手に入るわけですね。

f:id:kura_lab:20120228010554p:plain