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が使えるなら使っておきましょう。