#5 oauthの仕組み プロバイダーとクライアントでのやりとりを説明
今回はoauthについて講義したいと思います。
oauthは歴史的経緯でoauth2,oauth2.0と言うこともありますが、
今回はoauthと呼ぶようにします。
oauthを利用すれば違うドメインの違うDBで
同じアカウントで違うサービスを提供できるので大変便利な仕組みです。
かつ少し理解しづらいかと思いますので、今回取り上げました。
以前の開発でメインシステムとは切り離してサブシステムを開発して
そのサブシステムの認証でoauthを利用して全く別のシステム環境でサービスを
提供するといった案件があったのですが、
そのoauthの仕組みを話しても誰もピンとこなくて
Laravelのoauthのライブラリをインストールしてれば大丈夫と担当者が
思い込んでしまいサブシステム連携が全く進まなかった時がありました。
「AWSの洗脳」などの動画でも説明していますが、エンジニアの癖で
仕組みの原理を理解せずに機能を覚えたがります。
まさにこのoauthの件は機能を覚えて、原理を理解していなかった典型例です。
原理を理解することがとても重要なので今回oauthを取り上げた理由でもあります。
インスタグラムを例に挙げて説明していきます。
インスタグラムのログインページにいきます。
「Log in with Facebook」をクリックすると
facebookのログインページに飛ばされます。
このfacebookページに飛ばされた時にURIのパラメータで
どこに対しての認証を許可するのかという情報が必ず入っています。
URIを分解してパラメータをわかりやすくしてみます。
分解すると色々パラメータがありますが、一番重要なパラメータは
app_idです。
12から始まる番号がfacebookのDB上でインスタグラムだと登録されています。
そのapp_idのデータを保持しつつfacebookのログインページに遷移して
ユーザーネームとパスワードを入力すると認証されます。
認証された後Facebook側で
ブラウザはFacebookのログイン状態になります。
このユーザーの一時的な（３０分程度）トークンを生成してFacebook側のDBに
トークンとユーザーIDを登録します。
その後、そのトークンをパラメータとしてURIに追加して元のアプリつまり
インスタグラムにリダイレクトします。
インスタグラム側ではFacebook側で生成されたトークンを受けて
インスタグラムのサーバーサイド側からそのトークンとapp_idをパラメータに付けて
リクエストします。
リクエストを受けたFacebook側はトークンで合致したデータがあるのかどうかを
チェックして、データがあればuser_idを返して認証が成功したことを示します
トークンでの認証が通ればインスタグラム側でもFacebook側のレスポンスから
facebookのuser_idを取得して登録処理もしくは既に登録されていればログイン処理を行います。
この一連の流れでインスタグラムにはユーザーのパスワード情報を持たずに
ログインさせる事ができました。
セキュリティ的にはトークンの有効期限を決めてトークンの文字列を長くすれば
充分に安全を確保できます。
例えば、小文字大文字と数字で62文字ありその文字数を10文字にすると
兆の上の京の単位の８０京というパターンの数があるので、トークンをハッキング
しようとするならば８０京分の１の確率となり不可能な数値となります。
そもそもOauthのセキュリティ問題があるのであればGAFAを始めとした多くのIT企業
で使われていません。
oauthを利用することによって他のサービスのデータを借りる事ができるので
データベースを統合する必要がなく柔軟にデータのアクセス権も対応できます。
マイクロサービスや他の会社との連携など色々な局面においてとても便利なので
知っておいて損はないかと思います。
