OAuth

最近、TwitterのDMスパムなどで話題のOAuthですが、仕事で使ってみて色々思うところもあるのでまとめておく。

OAuthは安全か

まず、 OAuthでよく言われてるようにみえるパスワードをサービスに渡さないから安全ということに関して。簡単に言うと、「パスワード渡すよりは安全だけどまぁ信用していいかどうかの判断は必要だよね」ってところ。

OAuthは難しい話を抜きにしてしまえば、期限つきパスワード(Twitterは無期限っぽいですが)をサービスごとに発行するようなものだと思う。パスワードを渡した場合と違って、パスワードを書き換えられてログインできなくなるということはないが、APIで実行できることは基本的に出来るのでOAuthにもそれなりのリスクはある。

リスクと言ってもパスワードを第三者に渡すよりははるかに安全。先程述べたようにパスワードを書き換えられる心配もないし、仮に第三者のサービスからトークンが流出したとしても、トークンは無効化できるし、同一のパスワードを使っているサービスへの影響もない。(他のサービスと同じパスワードを使うのはどうなの?云々は置いておいて)

セキュリティより利便性

上記で述べたようにセキュリティ的にはパスワードを渡すより安全だが、ユーザ視点からみた場合のOAuthの利点はセキュリティ云々より利便性なんだと思う。

まず、パスワードの入力の手間が省ける。実際にIDとパスワードを入力してみればわかると思うけど、クリックで認証が済んでしまうOAuthの方が大分ラク。この辺は実装の詳細は違えど、利便性という意味では携帯の簡単ログインに近い。

また、パスワードを第三者のサービスに渡さないことでTwitterのパスワードを変更をする場合、Twitterのパスワードを変更するだけで済む。Twitterのパスワードを変える人がどれだけいるのか知らないけど。

サービス提供側としてOAuthを使うべきか

実際のところ、OAuthを使ったところでやることはあまりかわらない。当然、OAuthで取得したトークンが外部に漏れてしまえば、そのトークンを使用してTwitterへの発言やFollowingのremoveなどができてしまう。よってトークンが外に漏れないよう管理する必要がある。まぁそもそもデータが外部に漏れるということ自体があってはいけないことだけど。

だけどパスワードを預かるよりはユーザにとっても自分達にとっても安全なのは間違いないし、自分達の責任が限定されるという点からもOAuthを使うべき。その方がリスクが少ない。

例えば、他の同一パスワードを使用しているサービスで不正があった場合に、OAuthであればパスワードを持っていないので自分達のデータからパスワードが漏れるということがないし、そういう疑いをかけられることもない。

OAuthを使う際、サービス内部にOAuthを使用してなにをするのかを明記しておくといい。OAuthの仕組みなどを説明する必要はないが、自分達がTwitterに対してなにをするのかぐらいは書いておく方がユーザも安心できる。

現状、TwitterのOAuthの認可のページがかなり不親切かつほとんど英語なので、そのあたりは自分達でうまくサポートするしかない。

まとめ

パスワード使うよりはユーザにとってもサービスを提供する側にとってもメリットがあるのでOAuthが使えるなら使っておきましょう。

OAuthの細かい説明は抜き。

まず、OAuthを使うためにはTwitterでアプリケーションの登録が必要なので、http://twitter.com/oauth_clientsで登録をしておいてください。 以下のコードの6行目の部分を取得したConsumer keyとConsumer secretをに置き換えてください。

適当なところからverifyアクションにリダイレクトしてくると、さらにTwitterにリダイレクトします。その後、callbackアクションに戻ってくるので、そこで認証して取得したトークンをUserモデルに保存します。(ここでは自分のサービスにログインしているユーザが認証を行っています。)

その後、保存したトークンを使ってTwitterに発言をします。リクエストが受け入れられなかった場合の処理などは省いてます。

Twitterには取得したトークンに有効期限はありませんが、有効期限が存在するものもある(どちらかというとそっちの方が多いのかも)気をつける必要があります。

ちなみに細かいことを調べていないので「トークンをDBに保存してしまっていいのか」とか「トークンが外部に漏れてしまった場合はどうしたらいいのか」などについてはよくわかっていません。