RFCになったOAuth 2.0を使ってGoogleはどれだけパスワード入力を減らせるのか

※ 2012/10/17 少し文章を修正しています。

こんばんは、ritouです。
OAuth 2.0(とBearer Tokenの使い方)がRFCになりました。

最新仕様に合わせてAPIを提供しているサービスはついに「OAuth 2.0の最新仕様(Draft 31)」じゃなくて「RFCで定義されているOAuth 2.0の仕様」とか言えるわけですね。
せっかくなので何か書こうと思ったところで9月末ぐらいに流れていたGoogleの話を思い出しました。

先月出されてたブログエントリ : Google Developers Blog: Adding OAuth 2.0 support for IMAP/SMTP and XMPP to enhance auth security
OAuth 1.0時代のブログエントリ : OAuth access to IMAP/SMTP in Gmail - The official Google Code blog

これらについては以前も関連エントリを書いたことがありました。

OAuthの前に立ちはだかるPIMの壁 - r-weblife

何の話か

OAuth 2.0とはWebサービス間のAPI連携だけではないことはもう知られていると思います。
RFC6749ではモバイルアプリケーションやクライアントアプリケーションからのAPI連携の方法も定義されており、RFC6750(Bearer Token Usage)ではHTTPリクエストに署名を使わずAccess Tokenのみを指定する方法が定義されています。

Googleはさらに、HTTP以外のプロトコルについても、OAuth 2.0のAccess Tokenを利用したいと考えているようです。
細かい仕様はリンク先を確認してください。

【GMail】IMAPのAUTHENTICATEコマンド OAuth 2.0 Mechanism | Gmail IMAP | Google Developers
【GMail】SMTPのAUTHコマンド
【Google Talk】XMPPのauthエレメント OAuth 2.0 Authorization | Google Talk for Developers | Google Developers

OAuth 2.0で外部サイトにID/PWを入力させることを避けることができます。
しかし、メーラーやメッセンジャーアプリケーションに今まで通りユーザーのパスワードを入力していると、そこから意図せぬ漏えいや起こったり悪用されることも考えられます。

Googleは"2段階認証"と呼ばれるオプショナル機能において、このようなアプリケーション専用のID/PWを提供しています。プロトコルでID/PWが要求されるのは仕方ない、ならば専用のID/PWにして漏えい/悪用時のリスクを防ぎたいということのようです。

今回は、それらのプロトコルを拡張してOAuth 2.0のAccess Tokenを指定できるように考えましたという話ですね。
例えAccess Tokenが漏えいしても必要最低限のscopeが設定されていれば被害が抑えられるかもしれません。

ブログエントリのコメント欄を見ると、
「オレのXMPPサーバーが gmail.comのXMPPサーバーとお話しできなくなったんだけどこれの影響か？」
なんて書かれてるのでGoogle TalkのXMPPサーバーでは既存のEmail/PWではもう使えなくなったのかもしれません。

ちょっと気が早いような。。。

ユーザーから見たらどうなるのか？

iOS/AndroidとかのメーラーでGmailを読もうとするとき、こんな感じになります。
OAuth 1.0時代のエントリに含まれていた画像を引用します。

(引用元 : http://googlecode.blogspot.jp/2010/03/oauth-access-to-imapsmtp-in-gmail.html)

真ん中がGoogle上でOAuthの同意をしている部分です。アプリにパスワード入れる必要がありません！
（と言いたいところですが、この画像ではアドレスバーも見えないし逆にフィッシングされてもわかりませんね。霊界に住む死者からの通信などでフィッシングの危険性を指摘されてしまうこのような実装はOAuth 2.0の課題です。）

また、PCにメールクライアントをインストールして使ってる場合は、（Thunderbirdさん...）
今だと、SMTPの設定するときにこんな感じになるところを、

ベンダーが頑張って「OAuth 2.0」が選べるようになり、

実際に使うときはこんな感じでOAuthのフローを踏むようになります。

このToken取得のフローやAuthorization CodeなのかImplicitなのかとかは定義されていません。
取得したAccess Tokenをメッセージに含む部分だけが定義されている状態です。
XMPPもだいたい同じですね。

これ流行るのか？

前にも書いた通り、プロトコルレベルでユーザーのパスワードを必要とするものがたくさん残されています。
広くサービスを展開しているGoogleやYahoo!などにとっては、これらが悩みの種となっているのではないでしょうか。

OAuth 2.0で安全にできる、それはわかってもらえるでしょう。
しかし、現実問題としてクライアントの対応コストとメリットなどを考えるとGoogle一社だけでこんな動きをしても微妙なのではと思います。
IMAP/SMTPに関しては米Y!などメールプロバイダと協力したり、XMPPだとメッセージ周りに使っているSNSとかと協力して突き進めばもっと勢い付くのではないでしょうか。
あ、そういえば、mixiもXMPPで友人とチャットできるようになりましたよね。Perl Oceanとmixiのチャット機能トライアルの紹介 - mixi engineer blog

アプリベンダーに使ってもらう際に気になること

GoogleのドキュメントにはAccess Tokenの指定のところしか書かれていません。
このドキュメントを読んでアプリ開発者が手を動かすにはこのあたりのドキュメンテーションやサンプルが必要かなと思います。

Client IDの扱い : ベンダーが取得してハードコーディングではよくなさそう。Dynamic Client Registrationでやる？
scope : 他のOAuth Serverもこの方式にのってきてもらわないと流行らないだろう。その場合、より標準的なscopeの値を考えた方が実装しやすいと思う
Token取得フロー : アプリが頑張ってOAuth 2.0のフローを実装しなければならない。PublicなクライアントだけどAccess TokenのRefresh必要だよねとかけっこう実装めんどくさくなりそう。Googleの場合はInstalled Appとモバイルアプリで使えるresponse_typeが別れてたりで微妙に複雑。

日本でもY!Jさんあたりはこのあたり考えてみても良いのではないでしょうかね。

秋田からは以上です。