Qiita APIが第３者のアプリケーションに提供されるときにはOAuth 2.0で実装されることを願う

こんばんは、ritouです。
今日はTwitterでQiita APIにつっかかりそうになったのでその中で考えたことを残しておきます。

はじめに思ったこと

  • 個人の投稿の作成/更新/削除までさせるんだな
  • さすがにその時はTokenを使うんだな
  • Tokenはユーザーの識別子(Twitter/Github)とパスワード(Qiita上で設定)で取得か

で、

なぜOAuthでやらないのか

という感じです。

仕様確認

んで、TLで中の人じゃない人と話して仕様について以下のような指摘を受けた。

  • QiitaにログインするのはTwitter/GithubのOAuthであり、Qiita上で設定するパスワードではログインできない
  • Qiita上で設定するパスワードはMacアプリケーション「Kobito」利用のために必要
  • Qiita上で設定するパスワードではユーザーアカウントを無効化したりそのパスワードを変更できない
  • Qiita APIは権限移譲のために提供されている感じではない

(2012/10/11追記:開発者の方から個人利用向けとのコメントをいただきました！)

「プログラマのための技術情報共有サービス」だし、プログラマが自分の開発環境とかから
気軽に投稿見たり投稿したりするためにAPIアクセス専用のパスワード設定して使うならいいのでは。

と、少し心も落ち着きました。
Qiitaのブログを見ても

Qiita APIではQiitaから様々なデータを取得したり投稿の実行することが可能です。 さらに、投稿のストック/ストック解除も可能になりました！

QiitaAPIを公開しました！ - Qiita Blog

としか書いていないので外部からユーザーの代わりにがんがん使えとまでは書いてない。
使うなとも書いてはいないが。
このあたりはハッカソンで何か聞けると思うのだけど残念ながら参加できない。
もしかしたら、

OAuth言いたいだけちゃうんかこのID厨め！

と誰かに言われているかもしれない。

とはいえ気になる点

今回のような実装をされて心配だなーと感じた点がこちら。

  • ユーザーの意識 : Macアプリとの連携に必要なのはわかった。けど、そのアプリ使ってないユーザーにパスワード設定させることは「他のサービスとの使いまわし」が発生してそう
  • 意図しない利用 : APIのドキュメントなどを読んで、外部のアプリケーションでユーザーのパスワード入れさせて叩いてくる使い方により「外部にパスワード入れる」処理が復活したら嫌
  • 模倣サービス : 「ログインできないPW用意して、APIアクセスはそれとToken交換もしくはBasic認証とか実装簡単だし便利じゃね？」というAPI提供者が出てきてOAuthじゃなくこの形式が流行ったら嫌

考えすぎかもしれない。が、あえて考えすぎておきたい。
ということで、タイトルの通り、

外部のアプリケーションからAPIを利用させようと思ったらOAuth 2.0にのっとって実装されることを願います。

ではまた！