こんにちは！ミクシィの鈴木理恵子です。第1回目はユーザーがアプリをどのように判断して「許可」したらよいか、開発者は許可をもらうために何をしたらよいのかを取り上げました。第2回目は「OAuth」の概要と、OAuthを利用する開発者が知っておきたいマナーを取り上げました。今回は補足としてディレクター・開発者の皆さまの質問に答えていきながら、OAuthの連載のまとめをします。

Q1．OAuth連携時に許可画面が表示され、その際のユーザー離脱率が高くなっているようです。サービスの活性化のためにも許可画面を何とか出さないで済む方法はありませんか？

A1．このような感想を持たれるディレクターや開発者の方は多いです。

　前回、前々回の復習になりますが、許可画面ではmixi等のAPI提供者に登録してあるユーザーの情報へ、API提供者とは関係のない別のアプリがアクセスしてよいかを確認しています。ユーザーの立場に立てば、自身の個人情報を信用しているアプリにだけ開示できる（＝パーミッションコントロール）大切な画面です。

許可画面は、アプリがAPI提供者とは別の事業体で営まれている以上、必ず必要になります。なぜならAPIを利用して扱うものはユーザーの個人情報・プライバシーであり、事業体ごとにポリシーが異なるためユーザーの同意を得ないわけにはいかないからです。ユーザーの同意なく情報を開示してしまうと、信用問題になってしまいます。 「A子だけに言うけど、Bくんのことが好きなの。絶対内緒だよ！」……と、約束したのにいつの間にかみんなが知ってる、なんてほろ苦い経験ありませんか？私の同意を得ずにみんなに話してしまうなんて、親友のA子のことを信用できなくなりますよねっ！ 　ただし、例外的に許可画面を出さない場合もあります。それは同一事業体（あるいはそれと同等）で行われているサービスで、元のサービスに大きな変更を与えることなく新たなサービスを統合したい場合です。例えばミクシィ社が今年リリースした「mixiバースデー(http://mixi-birthday.jp/)」というサービスは、APIを利用してmixi本体と通信しています。これはミクシィ社自身が提供しているサービスなので、認可画面は表示していません。

　実は、OAuthの仕様上は許可の取り方の規定は明記されていません。許可が取れていれば、このように許可画面を表示しないこともできます。

　しかし一般的なアプリ開発ではこの例外には当てはまらないので、許可画面は表示する必要があります。もちろん、API提供者側もよりユーザーにわかりやすい許可画面にする努力が必要です。ですが、アプリ側でも工夫をすることができます。どのような機能のアプリなのか、どのような情報をAPIで扱うのかを事前にユーザーにわかりやすく伝えることで、許可画面の心理的ハードルを下げることができます。ユーザーが許可画面でどのようにあなたのアプリを判断するかについては、第1回目の記事『アプリの「許可」ボタン、簡単に押していませんか？』をご参照ください。

Q2．許可画面のデザインがうちのサービスのデザインにマッチしないのですが、許可画面のデザインを変えることはできますか？

A2．なるほど。例えばモノトーンで統一したクールなデザインのWebサービスにmixiのオレンジ色の許可画面が出ると違和感を感じる方が多いかもしれませんね。（図1,図2）

　許可画面のデザインについてOAuth2.0の仕様で規定があるわけではありません。なので、もちろん画面デザインは各API提供者により異なります。中には開発者側に画面デザインのカスタマイズを許しているサービスもあります。詳細は各API提供者にご相談ください。

　なお、mixiの許可画面がオレンジ色のテーマになっているように、許可画面のデザインが各API提供者らしいデザインになっているのには理由があります。mixi内のユーザー情報へのアクセスを許可しているとユーザーが直感的にわかりやすくするためです。アプリはAPIを複数組み合わせて利用することもあり、例えばmixiとTwitterのAPIを利用する場合はそれぞれの許可画面をユーザーに表示します。どちらがmixiでどちらがTwitterなのか、オレンジ色と水色であればユーザーにとってわかりやすいですね。

Q3．仕様が変わるとそれを利用しているアプリやサービスも修正を余儀なくされます。どうしてOAuth2.0は仕様が頻繁に変わるのでしょうか？

A3．確かに、すでにリリース済みの場合サービスを止めることもできず、開発者からすれば非常に迷惑なお話だと思います。

API提供者はどのように仕様を決めているのでしょうか？API提供者が提供する「OAuth」の仕様は、OAuth自体の仕様＋各社のセキュリティ・プライバシーポリシーで決められています。例えば、アクセストークン（＝APIの利用券）がどんなものか、どのように発行されるかは「OAuth」の仕様で決められていますが、その有効期間は具体的には規定されていません。mixiの場合有効期間は15分間ですが、これはmixiのセキュリティ・プライバシーポリシーにより決めています。 　実は「OAuth2.0」の仕様は依然策定中で、OAuthをテーマにしたこの3回の連載中（＝約3カ月）でも仕様がver.25→ver.27まで進みました（※1）。デバイスが多様化する中、より幅広い利用方法に対応するため議論が続けられています。そのためAPI提供者によってOAuth2.0の対応状況に違いが出ています。mixiの場合は現在ver.10（※2）に対応していますが、今後先のバージョンに対応する可能性もあります。 　セキュリティ・プライバシーポリシーは各社異なりますが、時流やユーザー・識者の考え方なども影響します。先日Facebookが無期限で利用できていたアクセストークン（＝APIの利用券）を有期限に変更しましたが、これはユーザー等の声を取り入れて変更したのだろうと推測します。 　発展途上のOAuth2.0ではありますが、多くのサービスで利用されている方法に準じていたり、その多くは最新仕様にも追従していくと考えられるなど、今後もしばらくは標準としてあり続けると思います。

Q4．OAuth2.0をやってみたいのですが、簡単に試す方法はありますか？

A4．OAuthに関する詳細な仕様説明や通信方法については、Web上に沢山の記事がありますのでそれらを参照してみてください。またmixiはOAuth2.0を提供しており、実際にAPIを利用することができます。日本語のドキュメント(http://developer.mixi.co.jp/connect/mixi_graph_api/api_auth/)を用意していますので、ぜひ一度お試しください。

　mixiもそうですが、開発者向けドキュメントにWebアプリケーション用のサンプルコードを掲載していることもあり、多くの方が実際にWebアプリケーションを作成してOAuth2.0を試しているでしょう。しかしながらOAuth2.0は仕様がシンプルなので、コマンドラインのHTTPクライアントであるcurlコマンドを利用して気軽に試すこともできます。Mac OSであれば標準でcurlコマンドがインストールされています。

　下記は、mixiでアクセストークン（＝API利用券）を取得するときのcurlコマンドの例です。

curl 'https://secure.mixi-platform.com/2/token' \
-d 'grant_type=authorization_code' \
-d 'client_id=(1)' \
-d 'client_secret=(2)' \
-d 'code=(3)' \
-d 'redirect_uri=http://www.myapp.com/callback'

{"refresh_token":"362d2bcfd7ad102a1fbeef789f55b033e53dad42","expires_in":900,
"access_token":"9dd83b5a3abbf47b63ee8bf2c5490e62d60f7aaf","scope":"r_profile"}

(1) あなたのアプリケーションのConsumer Key (2) あなたのアプリケーションのConsumer Secret (3) 許可後に発行されるAuthorization Code 　またmixiの開発者向けページ(http://developer.mixi.co.jp/connect/mixi_graph_api/mixi_io_spec_top/examples/)にて、OAuth2.0で許可を取り、APIでプロフィールを取得するサンプルコードを公開しています。ぜひご参照ください。 Erlang, Go, PHP, Ruby, Java, Java(Android), Objective-C, Clojure, Scala, JavaScript, Bash, VBA, Python, Haskell, C++, C

　OAuthに関する詳細な仕様説明や通信方法については既に多くの良記事があり、そういった面では比較的よく知られている技術と言えるかもしれません。しかし、ディレクター・開発者さんにとってはもっと現実的なつまずきポイントがあり、それを初心者向けに"ゆるふわ"にお話してきました。皆さまのアプリ開発の参考になれば幸いです。OAuthについては今回でひと区切りとなります。どうもありがとうございました！