• はてなブックマークに追加
  • Yahoo!ブックマークに登録
ミクシィ鈴木理恵子の“アプリ開発ビギナー向け講座” Vol.
2
本当に知ってる?
最低限押さえたいOAuthのマナー
Webサービスやアプリでユーザーの情報を見たり、書き換えたりするために事前に承認してもらうための「許可」ボタン。今回は「OAuth」と呼ばれる「許可」の仕組みと、最低限押さえたいOAuthのマナーを紹介します。
(取材・文/鈴木理恵子 総研スタッフ/宮みゆき 撮影/佐藤聡)作成日:12.05.17
「許可」をもらってAPIにアクセスするための仕組み「OAuth」

 前回は、Webサービスやアプリを使っているとよく見かける「許可」ボタンについて、ユーザーの立場に立って解説をしました。「許可」ボタンは、ユーザーが情報を預けているサービス(SNS等)とは別の第三者(アプリ)が、ユーザーの情報を見たり、書き換えたりするために、ユーザーに事前に「許可」を取るためのものでしたね。そして個人情報を収集するスパムアプリの被害を受けないために、ユーザーが「許可」ボタンを押してよいアプリかどうかを判断する方法を3ステップでご紹介しました。

「許可」の仕組みは技術的には「OAuth」(オーオース)と呼ばれ、特にWeb系の開発者にはご存じの方も多いと思います。OAuthは処理を代行してくれるライブラリ等が充実していて、簡単に「動かす」ことができます。しかしOAuth利用の前提となるマナーを理解していないために、知らず知らずのうちにユーザーの信頼を失いかねない行為をしてしまう開発者を度々見かけます。今回はOAuthの概要とともに「最低限押さえたいOAuthのマナー」を3つご紹介します。

 まずはOAuthの概要をご説明します。SNS等が提供するAPIを利用すると、アプリへ簡単にリッチな機能を組み込む事ができます。例えば最近のつぶやきをAPIで取得して表示するだけでも立派なアプリになります。またユーザーの友人に対してAPIでアプリの招待を送り、アプリの利用ユーザーを増やすことも簡単です。

 開発者の立場からするとAPIは非常に便利で、できるだけ様々な情報にアクセスしたいと思うでしょう。しかしユーザーの立場からすると、自分の個人情報を知らない人に勝手に利用されるのは怖いことです。そこでユーザーの情報を含む多くのAPIは、アプリがユーザーの情報にアクセスすることをユーザーが「許可」していないとアクセスできないようになっています。このような、“情報の持ち主に「許可」をもらってAPIにアクセスするための仕組み” は「OAuth」という名前で、世界中のサービスで標準として利用されています。

OAuth1.0とOAuth2.0

 OAuthは最初「OAuth1.0」や「OAuth1.0a」という仕様を作成し、多くのサービスが採用しました(※1)。しかし、処理が複雑で開発者の実装の負担が重い等の課題があり、新たに「OAuth2.0」という仕様を作成しました(※2)。「OAuth2.0」は処理がシンプルで開発者がより簡単に実装でき、既に「mixi」や「Facebook」など多くの先進的なサービスが採用しています。今回は「OAuth2.0」についてお話します。

OAuth2.0

「OAuth2.0」は多様な形態のアプリで利用されることを想定していて、いくつかの認可方法(=許可をもらう方法)が定義されています。そのうち一番基本となる認可方法をご紹介します(※3)。流れは次の通りです。

1:アプリの「身分証」と「暗証番号」をもらう(事前準備)
2:ユーザーの確認とアクセス許可をもらう
3:「API利用券」に引き換える
4:再発行する

 では、詳しくみていきましょう。
※以下、便宜上APIを提供しているサービスを“SNS”と表記しますが、実際はこの限りではありません。

1:アプリの「身分証」と「暗証番号」をもらう(事前準備)

 まず事前にSNSから2つの値が与えられます。この2つの値はそれぞれ、mixiでは「Consumer Key」「Consumer Secret」、Facebookでは「App ID/API Key」「アプリの秘訣」という名前です。「Consumer Key」はどのアプリかを特定し、「Consumer Secret」でアプリが本物かどうか判断します。それぞれ身近なものに例えると、「身分証」と「暗証番号」です。

2:ユーザーの確認とアクセス許可をもらう
アプリの「身分証」と「暗証番号」をもらう(事前準備)

 APIを利用しユーザー情報へアクセスする時がきたら、SNSに依頼をしてユーザーにアクセス許可をもらいます。
 アプリから依頼をされたSNSは、アプリに代わってユーザーに以下の2点を確認します。

(1)SNSのユーザーであることを確認(ログイン)
(2)アプリがユーザー情報へアクセスしてよいかを確認(許可画面)

ユーザーの確認とアクセス許可をもらう

 結果はSNSからアプリに伝えられます。SNSのユーザーと確認されかつアクセスの許可ももらえた場合は「Authorization Code」と呼ばれる「引換券」がアプリに渡されます。

 さて、なぜSNSに依頼しているのでしょうか?アプリが直接ユーザーに確認してはいけないのでしょうか?(1)を確認するにはログインID/パスワードが必要です。もしアプリがユーザーから直接ログインID/パスワードを受け取ったら、この時点でアプリはユーザーになりすまして自由にユーザーの情報にアクセスできてしまいます。アプリにログインID/パスワードを知られることなく確認するために、SNSに依頼をしています。

3:「API利用券」に引き換える

 次に「引換券」とアプリの「身分証」「暗証番号」をSNSに渡し、「Access Token」と呼ばれる「API利用券」をもらいます。この「API利用券」はアプリがユーザーにアクセス許可をもらっていることを示していて、有効期間内であれば何度でもAPIを利用することができます。もし写真を取得してもよいとユーザーから許可されていれば、写真を取得するAPIを利用することができます。「API利用券」はAPIを利用する時に一緒にSNSに渡して使います。

「API利用券」に引き換える
4:再発行する

 引き換え時に、「Refresh Token」と呼ばれる「再発行券」ももらえる場合があります。「API利用券」の有効期限が切れたらこの「再発行券」を使い、SNSに「API利用券」を再発行してもらいます。

 基本のフローは以上です。OAuthの処理を代行するライブラリを利用している方も、この基本フローは理解しておくとよいと思います。OAuthの詳細な仕様の解説や実装の方法はすでにネット上に多くの良記事があるので、そちらをご参照ください。

最低限押さえたいOAuthのマナー

 次に、「最低限押さえたいOAuthのマナー」を3つご紹介します。意外と知られていないのですが、どれも社会的な信頼に関わる大切なマナーです。今までにご説明したOAuthの概要を把握していれば、どれも理由をご理解頂けるかと思います。

マナー1:「暗証番号(Consumer Secret)」は大事に!

 アプリの「暗証番号」である「Consumer Secret」はアプリが本物だと証明するためのものです。誰にも盗まれないよう大事に扱ってください。もし盗まれてしまうと、あなたのアプリになりすましてユーザーの情報等を収集されてしまう可能性があります。「Consumer Secret」の管理責任はアプリ管理者にあります。

 github等にソースコードをコミットする時は「Consumer Secret」が含まれていないか確認しましょう。知らず知らず公開してしまっている例を見かけます。

 また、よくお問い合わせいただくメールの本文に「Consumer Secret」が書かれていることがあります。メールは通信の途中で内容を盗み見される可能性があり危険です。またメールはメーリングリストのように多数の人に自動転送されることもあります。メールには書かないようにしましょう。ディレクターや営業など非開発者の方は技術的な「Consumer Secret」の意味を知る機会がなかなかありません。開発者がフォローするのが好ましいと思います。

マナー2:「API利用券(Access Token)」は使い回してはダメ!

「API利用券(Access Token)」はユーザー毎に取得しなければならず(※4)、面倒に思うかもしれません。Aさんの「Access Token」を使って得た情報をBさんにも表示してしまおう……と考える方がいらっしゃいます。OAuthのフローでAさんに「許可」をもらいましたが、Aさんはなぜ「許可」をしたのでしょうか?Aさんは“Aさんがあなたのアプリを利用するため”に、アプリがAさんの情報にアクセスすることを許可したのではないでしょうか?同様に、アプリ1で取得した「Access Token」を他のアプリ2で利用するのもユーザーの意図に反しているでしょう。

 APIで取得できるのはユーザーにとって大切な情報です。ユーザーの信頼を失うことがないように気をつけましょう。

マナー3:スマホで取得した「API利用券(Access Token)」をサーバに送らないで!

 今回はご紹介していませんが、OAuth2ではスマホなどの端末上のアプリに対して直接「API利用券」を渡す認可方法があり、Facebookなどが採用しています。この利用券をそのままサーバ側のプログラムに渡してユーザーを認証してしまっているケースがよくあります。詳細はここでは触れませんが、なりすましの危険性があります。

 さて、今回はOAuthの概要と「最低限押さえたいOAuthのマナー」についてお伝えしました。ユーザーが安心して使えるアプリづくりの参考にして頂けたら幸いです。

(※1)Twitterは執筆時点でも「OAuth1.0a」を採用しています。
(※2)OAuth2.0は執筆時点ではドラフトのバージョン26です。http://tools.ietf.org/html/draft-ietf-oauth-v2-26
(※3)Authorization Code Grantという認可方法です。
(※4)OAuth2.0には、Client Credentialというアプリ毎にAccess Tokenを発行する方法もあります。
鈴木 理恵子

株式会社ミクシィ 技術部 コアプロダクト開発G所属。
青春時代はギター制作に明け暮れていたが、一転、IT業界に転身しプログラマとなる。
業務アプリケーションシステムの開発を経て、現在はミクシィでmixi Graph API等のアプリプラットフォーム開発を担当。

  • はてなブックマークに追加
  • Yahoo!ブックマークに登録

このレポートに関連する企業情報です

◎インターネットメディア事業/ソーシャル・ネットワーキング サービス『mixi』  ◎インターネット求人広告事業/Webな人の転職サイト『Find Job !』(株式会社ミクシィ・リクルートメント提供)続きを見る

あなたを求める企業がある!
まずはリクナビNEXTの「スカウト」でチャンスを掴もう!
スカウトに登録する

このレポートの連載バックナンバー

鈴木理恵子のアプリ開発ビギナー向け講座

ミクシィ鈴木理恵子が、アプリ初心者の方向けに、聞きたくても聞けないアプリ開発の初歩的なノウハウや失敗回避法などを伝授します。

鈴木理恵子のアプリ開発ビギナー向け講座

このレポートを読んだあなたにオススメします

ミクシィ鈴木理恵子の“アプリ開発ビギナー向け講座”

【OAuth/Q&A】アプリ開発者の生の声お伝えします!

鈴木理恵子のアプリ開発ビギナー向け講座これまでお伝えしてきたWebサービスやアプリでユーザーの情報を見たり、書き換えたりするために事前に承認してもらうための…

【OAuth/Q&A】アプリ開発者の生の声お伝えします!

スマートフォンの普及でセキュリティや個人情報が危ない

高木浩光が語る!プライバシーを守るのは真心である

ブログ「高木浩光@自宅の日記」で、独自にセキュリティやプライバシーの問題を指摘する高木浩光氏。「セキュリティ・エバンジ…

高木浩光が語る!プライバシーを守るのは真心である

ミクシィ鈴木理恵子の“アプリ開発ビギナー向け講座”

アプリの「許可」ボタン、簡単に押していませんか?

鈴木理恵子のアプリ開発ビギナー向け講座ミクシィ鈴木理恵子です。この連載では聞きたくても聞けないアプリ開発の初歩的なノウハウや、初心者が陥りやすい罠の回避法な…

アプリの「許可」ボタン、簡単に押していませんか?

利用者は5%、タブレットが人気、面倒くさいのは使用制限……

BYODが拡大中!エンジニアのお好みアプリと満足度

私物のデバイスを業務に使用するBYOD(Bring Your Own Device)の導入が、企業や自治体で拡大中だ。では、実際にどの…

BYODが拡大中!エンジニアのお好みアプリと満足度

ミクシィ鈴木理恵子の“アプリ開発ビギナー向け講座”

開発者のためのiframe内アプリのセッション管理方法

鈴木理恵子のアプリ開発ビギナー向け講座開発者を悩ませるiframe内表示Webアプリ問題。前回はその現状についてお伝えしましたが、今回はiframe内Web…

開発者のためのiframe内アプリのセッション管理方法

こんな時代に人事が欲しがる

年収1000万円超プレイヤーの自己投資術

不景気だから年収が下がるのは当たり前、と思ってはいませんか? 世の中には、こんな時代でも年収が上がり続ける「不況知らず…

年収1000万円超プレイヤーの自己投資術

この記事どうだった?

あなたのメッセージがTech総研に載るかも

あなたの評価は?をクリック!(必須)

あなたのご意見お待ちしております

こちらもお答えください!(必須)

歳(半角数字)
(全角6文字まで)
  • RSS配信
  • twitter Tech総研公式アカウント
  • スカウト登録でオファーを待とう!
スマートグリッド、EV/HV、半導体、太陽電池、環境・エネルギー…電気・電子技術者向け特設サイト

PAGE TOP