woshidan's blog

あいとゆうきとITと、とっておきの話。

いまさらOAuthについて調べてみた

OAuth セキュリティ

OAuthの認証周りにめちゃくちゃ苦手意識があったので、ちょっと調べてみました。

内容

  • OAuthとは
  • OAuthを使うと何が良いの
  • OAuth1.0と2.0とは

OAuthとは

ニュースメディア等のクライアントアプリが、Twitter、Facebookなどユーザ情報やユーザにひもづいたリソースをたくさん持っているSNSなど(サービスプロバイダ)と連携して、SNS上の情報をクライアントアプリ上で利用できるようにする仕組みです。

この仕組みでは、ユーザ(SNS上にアカウントを持っていて投稿などのリソースのオーナー)とサービスプロバイダ、クライアントアプリの三者が関わっています。

サービスプロバイダは、ユーザがサービス上に残している情報へのアクセス権減 & クライアントアプリからの認証 を特定のクライアントアプリに依存しない形で持ちます。

サービスプロバイダとしての挙動を実現するための代表的なgemとしては doorkeeper です*1。

後述する事情であまり突っ込む必要は無いかもしれませんが、OAuthはどういう仕組みで動くのか、少し大雑把にメモしておきます。

まず、クライアントアプリは、OAuthで連携しているサービスプロバイダの保管している情報が必要になった際、 ユーザにOAuth認証を開始させます。

この際、基本的には別ブラウザ*2でサービスプロバイダの認証・リソースへのアクセス認可をさせます*3。

認可・認証の操作を受けたサービスプロバイダは、認可/認証の情報を持ったリクエストトークンを持った状態で指定されたクライアントアプリのURLへリダイレクトさせます。

そして、クライアントアプリは、受け取ったリクエストトークンを持って、サービスプロバイダにアクセストークンを発行してもらいます。

そうしてようやく、そのアクセストークンを使ってサービスプロバイダ上の情報にアクセスします。ややこしいですね。

この通りややこしいので、みんなOAuth実装周りはライブラリで済ますのが慣例となっていて、ライブラリが無い言語やアプリではなかなか開発されない事もあるようです*4。

OAuthを使うと何が良いの

そんなOAuthを使った場合のメリットについていくつかあげてみます。

はじめに、ユーザから見た時のメリットは

  • 登録にパスワードなどの入力が省ける
  • プロフィールの入力が省ける
  • 複数のサービスでパスワード等を別個に管理しなくてよい

あたりでしょうか。

次に、サービスプロバイダから見た時のメリットは

  • サービスに新たな利用法が生まれ、サービスが活性化する

これは、OAuthというより、WebAPIを公開する利点でぐぐった方が早そうです。

最後に、クライアントアプリのメリットは

  • ユーザの登録の手間の減少
  • 嘘プロフィールの減少
  • 自サービス上でユーザ情報を管理しなくても、ユーザ情報が利用できる(セキュリティ問題の回避)
  • シェア等が増える可能性

などがあります*5。

OAuth1.0と2.0とは

OAuthには、1.0と2.0があります。OAuth2.0と1.0は何が違うのでしょうか。

いまでは、2.0がデファクトスタンダードなので、1.0について調べるのは好奇心以外意味はないのですが、一応下記の記事を参考にまとめてみます。

http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html

  • OAuth2.0とOAuth1.0の違い
    • HTTPSを必須にし、署名をなくし、トークン取得も簡略化
      • OAuth1.0ではHTTP通信を許可していたため、盗聴/改竄の危険性があり、リクエストに改竄の無い事を示す書名をつける必要があり、リクエストトークンの取得を煩雑化していました
    • アクセストークンのみでリソース取得が可能に
      • リクエストトークンが無くなり、認可後の認可トークンを送れば、サービスプロバイダからアクセストークンが受け取れるようになりました*6
    • Webアプリも含め、4つのクライアントプロファイルを仕様化
      • 以前はWebアプリに対してしかクライアントアプリの仕様が無かったりしたのですが、Webサーバ / ユーザーエージェント*7 / ネイティブアプリ*8 / 自立クライアント*9 に対して仕様が策定されました

たぶん、

  • サービスプロバイダへの通信はHTTPS必須になったけど、その分セキュリティのためのやり取りが減って便利になったよ〜
  • リクエストトークンを保存しておく必要のあるステップが減って、リクエストトークン保管用のリソースが減らせるよ〜
  • Webアプリ以外からも使えるようになるよ〜(多分)

という違いみたいです。

まだ理解がふわふわしているので、今度、doorkeeper gemがどう動いているのかをもう少し調べてみようかと思います。

*1:まだ、ちゃんと読めてない...

*2:クライアントアプリにサービスプロバイダのパスワード等を渡さないための処理ですが、Referesh Tokenなどの仕組みの利用のためや認証用ライブラリの活用のため自サービスサーバ/クライアント間でOAuthを使う場合もあるらしい...? http://qiita.com/ledmonster/items/0ee1e757af231aa927b1

*3:Facebook連携アプリで、このアプリはXXにアクセスします、許可しますか...とか表示される奴ですね

*4:参考: http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html

*5:多分、もっとあります。この辺とか http://www.forumsys.com/api-cloud-solutions/api-identity-management/oauth/?gclid=Cj0KEQjwyK-vBRCp4cymxermx-EBEiQATOQghwp7s7HBoIGbf-ClM56iBwbPEcmcf0UcFGhjiWlVEB4aArXT8P8HAQ

*6:本音では、図から認可コードとリクエストコードが何が違うのか少し分からないのですが...

*7:JSから叩ける奴らしいです

*8:モバイルですね! ガイドライン程度しか無いそうですが...

*9:SAML...?