突然のメール
AtomでGmailにOAuth2でアクセスするためのパッケージのソースにclient_secret.jsonをつけていることについて、「i saw what might be some private credentials.」なるメールが届いたのが数日前。
英語に詳しくないのだが、多分「プライベートな認証情報が丸見えやで。」っていう意味に取れる。
配布前にも少し悩んだのだが、もう一度client_secret.jsonを配布物に含むことで発生するリスクと考えられる対応方法などを素人なりにまとめてみて、識者からの教えを請いたいと思う。
client_secretを悪用されてのリスク
client_secretの乗っ取り
まずすぐに思いつくのがこれ。
同じような名前のパッケージを作り、Scopeとソースの一部を書き換えれば例えばユーザーのメール全てを読み書きすることが出来ると思われる。
この場合はソース配布者には損害がない(悪いうわさが広まって信用が無くなる可能性はある)が、ユーザーの個人情報が漏れてしまう。
でも、ユーザーの個人情報が漏れてしまうってのは乗っ取りに関係なく、信用しないプログラムは利用しないという常識(まあ、個人的にも拡張機能の類は検証なしに入れてしまうから常識とはいえだれも意識してないかもしれない)からみるとユーザーの責任になるのではないかと思われる。
そもそも、Googleからの認証の時にパーミッションが表示されているのでユーザーは開示に合意したことになるだろうし。
利用回数制限の回数が減る
ほかでも同じclient_secretが使われると利用回数が割増しになってしまうので、上限に引っかかる可能性が高くなる。
ユーザーには関係なさそうだが、利用者が増えてきた時はユーザーが利用できなくなるおそれがある。
とはいえ、Gmailの場合は 1,000,000,000 ユニット数/日 なので、初期設定(一分間隔)で使ってもらえば、およそ70万人の利用者にならないと問題は無い。ってことは同じような使い方をされてもほとんど問題ないよね。
デベロッパーコンソールの情報信頼性の低下
低下するというのが適切かどうかわからないけど、そのclient_secretを利用してのアクセス数を確認できるデベロッパーコンソールの情報が割増しされることになる。
まあこれについてもあんまり気にしなくてもいいかもしれない。本当に情報が欲しかったらGoogleAnalyticsなどを使うと思うし。
で、どのWebページのソースを見ても最後に載ってるコピーできるUA-なんちゃらと同じ位に考えて良さそう。
その他にはリスクあるのだろうか？
対応方法は？
いちおう 「Re: OAuth 2.0のclient_secretって本当に秘密鍵ですか？ 」あたりも読んではいるのだが、実のところは不勉強でどう対応したほうがいいのかが分からない。
- client_secretなんて実際はSecretなんかじゃないんだから気にしないで今の方法でもいいんじゃ？
- やっぱりclient_secretの配布は気持ち悪いので止めるべき。例えば利用者に個人でclient_secret.jsonを準備させればいいんじゃない？
- ちょっと使われたくらいは気にならないけど、念のため定期的にclient_secret.jsonを更新してバージョンアップしたらいいんじゃないの(ユーザー側で再認証の手間が増えるけど)？
- Golangあたりで作ったWin,Mac,Linux用のバイナリを添付してそこで認証の処理させたら少しはマシなんじゃないの？開発の手間は増えるけど。
とかの対応が考えられるのだが、どうしたら良いものなんだろう。
ちなみに、実装にあたっては Gmail API - Node.js Quickstart を参考に実装しているので処理内容には問題ないと思われるが、やはりサーバーサイドのNode.js用サンプルをクライアント用のAtomに利用するのは間違いだったのだろうか。
追記1（Client-sideアプリケーションパターンの場合に方向性を変えて検討してみる）
サーバーサイド側の実装例をクライアントサイド側に実装するから問題があるのかと思い Using OAuth 2.0 for Client-side Applications を検討してみた。
確かにこの方法だと client_secret は不要になるが、client_id は必ず必要になる(当たり前だが)。
ここで、 client_secret の代わりになるのがリダイレクトURLなのだとおもうのだが、クライアントで完結するようなプログラムでは localhost しか選択肢は無いと思われる。そうすると client_secret が丸見え状態と状態はほとんど変わらないように思える。
例えばHerokuあたりに実装したWebアプリケーションを一枚噛ましてそこからlocalhostへ再度リダイレクトさせるのが正しい実装方法ということになるのかな。うーんちょっと面倒なぁ。仕方ないことなのかなぁ。
ちなみに、Stackoverflowの Can I really not ship open source with Client ID? [closed] でも議論されてるようだが、英語でもう一つよくわからない。
追記2（Client-sideアプリケーションパターンを実装してみた）
「OSSのクライアントインストール型プログラム(Atom用パッケージ)でOAuth2をなるべく安全に利用する」 で実装してみました。