Love PG , Liquor & Music

プログラマー備忘録やお酒や音楽

【AOuth2.0とは?】なぜFacebookでみんな出会い系に「いいね!」してるのか。

Facebookのタイムラインをつらつらと眺めてると、ある出会い系のサイトの広告をよく目にします。

この広告、あの人もこの人も毎回こぞって「いいね!」なんてしてるもんだから
純粋な僕は、よっぽどいいサイトなんだ!!なーんて思って、思い切って登録してみました。

使ってみた感じ、サイト自体はよくできていていろんな機能があって技術的には関心したのですが、みんなが「いいね!」してるほどそんなに面白いもんでもなく1か月で退会しました。
パズドラの魔法石以上に無駄なお金使った気がして、ちょっと心が荒みました。
1月利用料2000円もしたので、まだ石30個買ったほうがよかったと反省してます。


さて本題です。実はこの友人の「いいね!」にはからくりがありまして、
出会い系の広告に対して僕の友達は自発的に「いいね!」を押してないんですよね。(善意で押してる人もいるかも?)

じゃあ誰が「いいね!」してるの?って思うと思います。
答えを先に言ってしまうと、インストールされてるアプリのどれかが「いいね!」を勝手にやってくれてます。なぜそんなことをするのかというと、9割方の理由は金です。広告費として無料で提供しているアプリなんかに組み込んじゃったりしています。残り1割は遊び心です。普段固そうなあの人に変なことつぶやかしたりしたいのです。


じゃあどのアプリが「いいね!」してるの?ってとこなんですが、

 自分の代わりに
  ・タイムラインに投稿したり
  ・「いいね!」押したり
  ・特定のユーザーをフォローしたり
 する権限をFacebookから与えられたアプリが犯人です。


はい、これだけじゃよくわからないですよね。

 

たとえばLINEを例に挙げます。
スマフォには
 ・LINE
 ・LINEポコパン
が入ってるとします。


ポコパンをなんとなくプレイしていると、
タイムラインに「○○さんがLINEポコパンでXXX万点ゲットしました。」
とかいう、どうでもいいけど投稿されるとちょっと恥ずかしい情報がいつの間にか書き込まれてたりします。
やってることはFacebookに勝手に「いいね!」されるのと同じです。

ちょっとそれますが、メッセージで「[LINEレンジャー] サリーを助けて!」とか心底どうでもいい情報も来たりします。これも上に書いたのと同じ機能を使っています。
決して、「久しぶりに携帯鳴ったらアプリの招待だった。」となんとなく切ない気持ちにさせるために相手が送ったものではないので安心してください。

この場合はLINEポコパンのアプリケーションにLINEへの書き込み権限をLINEが与えているので、LINEポコパンでハイスコアをとった時にタイムラインへアプリが自動で書き込みに行ってるのです。

この書き込み権限、だいたいアプリの初回起動時に設定がされるかSNS連携機能の設定画面から設定されます。
たぶん1度は見たことがあると思いますが、

LINEだとこんな画面

 

f:id:gwaan_so:20140526223858p:plain

 

これは

・あなたのLINE登録しているプロフィールを見ちゃうよー

・そしてあなたのLINEに登録されてる友達情報も取得しちゃうよー

・んで、その友達にメッセージも送っちゃうよー

・最後にタイムラインにもハイスコアとったら投稿してあげるよー!

って事の同意を求めています。


Facebookだとこんな画面

 

f:id:gwaan_so:20140526223937p:plain

 

これもLINEで聞かれていることと同じようなことを聞いています。


で「OK」とか「同意する」を押すとアプリに権限が付与されます。

 

アプリだったら起動さえしなければ投稿されることはありませんが、WEBアプリとかの端末にインストールする必要がないアプリでは消しても投稿され続ける可能性があります。

 

どのアプリにどんな権限を与えて何がされるかというのを把握とかないと、おちおちSNSなんかつかってられません。

ポコパンのように投稿する内容をある程度把握できてるのだといいんですが、ひどい事例だと、勝手にタイムラインに「おっぱいおっぱい\(^o^)/」なんて書き込むようなアプリもあるので、そんな投稿されて人様の目に触れようものなら、恥ずかしくてまともに外も歩けなくなってしまいます。

 

タイムラインに「おっぱいおっぱい\(^o^)/」と書き込まれないためには

ここから犯人探しをしていきます。

まず、何のアプリをFacebookと連携しているか知る必要があります。

パソコンなどからFacebookを開き、トップページの赤枠部分、ここにFacebook認証をしているアプリ一覧が出てきます。

Facebook公式アプリからは開けなかったのでスマフォしかない人はSafariとかChromeとかのブラウザからアクセスするとできます。

んで、怪しそうなアプリとか登録した覚えのないアプリ、使ってないのとかがあったらとりあえず削除をおすすめします。削除の方法はアプリ名の横にある歯車ボタンを押すとメニューがでますのでそこから「アプリを削除」を選びます。

 

f:id:gwaan_so:20140526224407j:plain

 

はい、これでとりあえずタイムラインに「おっぱいおっぱい\(^o^)/」と書かれる可能性がだいぶ減りました。

 

次にアクティビティログを確認しておきます。

ここの赤枠のとこの「全てのアプリ」をクリックします。

 

f:id:gwaan_so:20140526225424j:plain

 

すると、自発的にで投稿した内容以外(つまりFacebook連携を承認したアプリ)のログが出ますのでアプリが変な投稿していないか確認します。

ここでもし出会い系に「いいね!」してたり「おっぱいおっぱい\(^o^)/」と書き込んでるログがあったらそいつが犯人なので先程の手順で消しちゃってください。

 

はい、これで安心してSNSが使えますね。これを気に変なサイトに「いいね!」して僕みたいな純粋な被害者を一人でも減らせればと思います。

 

以上、普段からアプリ使ったりとAOuthを全く意識しないで使ってますね。僕もはてなの投稿なんか使ってますが、使いようによっては便利な機能です。

万が一「おっぱいおっぱい\(^o^)/」と投稿されても、攻めるべきはOAuthではありません。アプリが悪いのです。その時はおとなしく部屋に篭っておきましょう。人の噂もなんとやらです。

 

ここからは開発メモです。

AOuth2.0はただのログインツールと思われがちですが、僕の中の認識ではベンダーの異なるシステム間をつなぎ権限指定も詳細にできるSSOみたいな規格です。

似たような仕様で、OpenIdってのがありますがこっちは全く流行っておらず息していないので使うならあえてOpenIdを使う必要は無いと思います。

 

1点注意点ですが、OpenID,AOuth2.0ともに今月脆弱性が発見されました。

詳しくはCovert Redirectでググってみてください。結構やばいですが、OAuthの信頼ががた落ちしたくらいで組み込む分には問題ないです。

 

まずAOuthは何をしたいときに使うのか?

AOuthの利用は2通りあります。

① プロバイダーが用意したAPIを使いたいとき

APIを提供したいとき

 

まず、①についてです。

AOuthを提供しているプロバイダーはどこがあるのかというと、だいたい大手SNSは提供してて

Google

Facebook

Twitter

・Yahoo

なんかが提供しています。

 

それを使うっていうのはつまりどういうことかっていうと、例えば、自分で作成したアプリケーションからFacebookで登録しているプロフィール情報を抜き出したり、Twitterで呟いた過去の投稿を全て取得したりすることができます。

 

概要をOAuth2.0の仕様書http://tools.ietf.org/html/draft-ietf-oauth-v2-10)から抜粋すると、下の図のような感じです。

 

f:id:gwaan_so:20140526232039j:plain

 

ユーザーエージェントフローの手順は以下のようになっています。

(A)
クライアントはユーザーエージェントを Section 3 に記載されたエンドユーザー認可エンドポイントに送る. その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.
(B)
認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.
(C)
エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる. そのリダイレクトURIURIフラグメントには, アクセストークンが含まれる.
(D)
ユーザーエージェントはリダイレクト命令に従い, ウェブサーバーに対してリクエストを行う. このリクエストにはフラグメント情報は含まれない. ユーザーエージェントはフラグメント情報をローカルに保持する.
(E)
ウェブサーバーは, ウェブページ (一般的にはスクリプトが組み込まれたHTMLページ) を返す. そのウェブページでは, ユーザーエージェントはフラグメントを含む完全なリダイレクトURIにアクセスし, フラグメントに含まれるアクセストークン (およびその他のパラメーター) を抽出することができる.
(F)
ユーザーエージェントはウェブサーバーによって提供されたスクリプトをローカルで実行し, アクセストークンを抽出しクライアントに渡す.

 

つまり、(A)~(D)で自分のアプリとFacebookでの認証を行い、

Facebookへのリソースへアクセスしたくなったら(D)で取得したTokenを渡してあげれば欲しい値が取得できるってわけです。

んで、Tokenが死ぬまでは取得したTokenを利用し続けてリソースへアクセスしまくれるわけです。これでアプリ開発の幅がかなり広がりますね。 

ちなみに取得したいリソースへのリクエストはプロバイダーが指定している権限から詳細に設定してあげる必要があります。

FacebookについてはLogin Dialogに載ってます。

 

ココらへん利用して、そのうち開発サイドでのAOuthの組み込みについて書いてみようと思います。②についてもDoorkeeperなんか使って今度実装してみたいと思います。