oauthの仕組み プロバイダーとクライアントでのやりとりを説明
今回はoauthについて講義したいと思います。
#5 oauthの仕組み プロバイダーとクライアントでのやりとりを説明【講義】 - YouTube
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を利用することによって他のサービスのデータを借りる事ができるのでデータベースを統合する必要がなく柔軟にデータのアクセス権も対応できます。
マイクロサービスや他の会社との連携など色々な局面においてとても便利なので知っておいて損はないかと思います。
登録日：
更新日：