WebサービスやSNSに必須のOAuth(オーオース)とは何か? まとめてみました!

こんにちは。とむるです。

今回の記事では、OAuth(オーオース)の解説をします。今日では、OAuthの仕組みは、WebサービスやSNSの中で必須といわれるほど使われるようになってきました。

OAuthの仕組みを自分なりにまとめてみたので、よければご覧ください!

そもそもOAuthって何?

OAuth(オーオース)とは、一言でいうと、「アクセス権限が付与するためのプロトコル」になります。現在は、OAuth2.0が最新のものとして標準化されています。

OAuthは何に使われているの?

OAuthは、今やWebサービスやSNSに使うにあたって必須の機能になっています。WebサービスやSNSのマイカウントにログインするときにそのサービスのユーザーのログインによって認可する必要があります。

ただ様々なサービスがある中で、そのすべてのサービスのマイアカウントにいちいちログインして許可をもらうって非常に面倒ですよね。

例えば、Instagram上の設定画面からFacebook、Twittterなど複数の外部サービスに連携することができますが、写真をシェアしたいサービスごとにログインをしていくなんてあまりにもめんどくさいと思います。

しかしOAuthを使えば、Instagramのログインのみで、FacebookやTwitterへの同じ写真の投稿が可能になっています。

この処理を具体的に説明するとInstagramがOAuthによってユーザーの代わりに写真をアップロードするたびに、各サービス(Facebook、Twitter)が提供しているAPI経由で写真を投稿する仕組みとなっています。APIは、アプリケーション、プログラミング、インターフェースで外部アプリケーションの機能を共有するシステムのことです。

OAuthという仕組みが生まれたのは、Facebook、Twitter、GoogleなどのWeb連携サービスが急速に増加し、各サービスが増加し、各WebサービスのAPIを公開し、共有するためのAPIアクセスを認可する手段が必要不可欠になったことかがあげられます。そうして2007年にOAuth1.0が生まれました。

OAuth2.0とOAuth1.0の違い

いざOAuth1.0が生み出されたものの、課題が多く残されていました。その課題としては、

  • リクエストの認証や署名、リクエストパラーメーターが複雑だった点
  • Webアプリへの対応を優先したことから、デスクトップやモバイルアプリ(スマホアプリ)では使いにくい。
  • 認証システムが複雑で、サーバーをスケールしにくい。

といった問題点がありました。

そういった問題点に加えて。よりセキュアに改善したものが2012年にRFC(Requeset For Comments)として発行されたOAuth2.0になります。RFCとは、すべての仕様書などのドキュメントがインターネット上で公開され、、誰でも閲覧できる状態のことです。

OAuth2.0の具体的な役割

OAuth2.0とは、「クライアントアプリケーションによるアクセストークンのリクエストと認可サーバによるレスポンスを標準化したもの」になります。OAuthの具体的な役割をみるためにOAuthに関わる一連の流れを以下で解説していきます。

あるWebサービスやSNSを使っているとユーザーが持っているデータを別のサービスで利用したい場合がよくあります。この時、ユーザーのデータを利用したいWebサービス側をクライアントアプリケーション、ユーザーのデータを管理しているサーバ側をリソースサーバといいます。リソースサーバ側には、ユーザーのデータをやり取りするための窓口があります。これが先述したAPIになります。

クライアントアプリケーションは、ユーザーのデータをリソースサーバーにリクエスト(要求)します。この時、APIを守る仕組みがないと悪意があるクライアントアプリケーションは、リソースサーバ上のユーザーデータがとり放題になってしまいます。

こうした事態を防ぐために、認可サーバというデータ利用のリクエストを受け取るサーバを用意します。

認可サーバは、アクセストークンという「クライアントアプリケーションがユーザーのデータを利用することを許可されていることを示すトークン」をクライアントアプリケーションに対して発行します。

こうしたアクセストークンを保有しているクライアントアプリケーションのリクエストに対し、リソースサーバは、リクエストからアクセストークンを取り出し、そのアクセストークンがユーザーのデータを利用するアクセス権限を持っていることを検証して認可が下りれば、ユーザーのデータをクライアントアプリケーションに渡します。

以上が、クライアントアプリケーションとリソースサーバ、認可サーバの関係を表した一連の流れでですが、実際にはさらに、アクセストークンを発行する前に認可サーバは、ユーザーに権限を取るというステップがあります。

ユーザーがOAuthを利用して、サービス間関連を行うために、まずユーザーは、クライアントアプリケーションを認可サーバに登録する必要があります

クライアントアプリケーションがリソースサーバからデータを受け取るにはアクセス権限の譲渡が必要ですが、ユーザーがクライアントアプリケーションに許可をすれば、アクセス権譲渡の認可フローが開始されます

認可フローが開始されると、クライアントアプリケーションは、自らの識別情報と認可サーバへのAPIのアクセス権譲渡リクエストをリダイレクトします。

これは登録されたクライアントアプリケーションの情報とリクエストとの適合を認可サーバが行うためになります。

リクエストを受けた認可サーバは、ユーザーの認証を行った後に、ユーザーにAPIアクセス権譲渡してもいいかどうか(アクセストークンを発行していもいいかどうか)の確認を行います。

ユーザーがAPIアクセス権限を許可すると、認証サーバは、アクセストークンと一緒にクライアントアプリケーションへリダイレクトを行います。

最後にクライアントアプリケーションは、リソースサーバにリクエストを行い、リソースサーバは、リクエストに問題なければ、レスポンスを行います。

以上のような、クライアントアプリケーションによるアクセストークンのリクエストと認可サーバによるレスポンスを標準化したものが、OAuth2.0になります。

OAuthの仕組みを図示などを活用しながら直感的に理解したい方には、以下のサイトが参考になると思います。

一番分かりやすい OAuth の説明

以上、OAuthとは何か?をまとめてみました。リフレッシュトークンなどの話が書けなかったので、修正しつつ、第2弾を後日書きたいと思います。

 

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください