外部認証、身近なものでは “Facebookでログイン” とか “Googleでログイン” のことです。ユーザ登録は面倒ですし、パスワードも覚えていられないのであれば使われている方も多いかと思います。OAuth2 なのですがコンシューマ向けと業務サービスでは構成、シーケンスに違いがあります。なぜか？というお話です。
最初に業務サービスのの場合の認証シーケンスの例をご紹介しましょう。
ユーザーは認証サイトBにログインし業務サービスを利用していますが、あるオプション機能はサイトAのものだとします。まだサイトAにログインしていないので、オプションメニューをクリックすると、認証トークンが埋め込まれたサイトAへのログインページがサイトBから返されます。ここがポイントで、サイトAへのログインページをサイトAのセッションで返されると、認証トークンをサイトBから得るセッションがブロックされます。なのでサイトAにログインするページはサイトBから返してもらう必要があります。サイトBは有効なセッションをもつユーザー（ブラウザー）に対してサイトAの認証を代行します。認証OKの場合はトークンを返します。トークンはサイトAから提供された秘密台帳による署名付きです。
ログインページはブラウザーのリダイレクション機能を使って直ちにサイトAにアクセスします。認証トークンはサイトAの秘密台帳で検証されログインが成立、ユーザーはサイトAの提供するオプション機能を利用できるようになります。
さて同じことをコンシューマ向けサービスで出来るでしょうか？サイトBを Facebook 、サイトA を転職情報サイトとでもしましょう。Facebookにログインしているユーザーが転職情報サイトのバナー広告をみてクリックします。しかしここで引っ掛かります。サイトAへのログインページです。Facebookに自由にWebページを配置することはできません。このようなシーケンスになります。
１．サイトBページ→サイトA（バナー広告のクリック）
２．サイトAページ→サイトB（リダイレクション、認証要求、トークン発行）
３．サイトBページ→サイトA（リダイレクション、認証トークン検証、ログイン成立）
４．サイトAページ
これが本来のOAuthの流れなのですが、業務系の場合は１と２をセットで行い、３へ行くことができます。被認証サイトへのログインページを認証サイトに配置できるとシーケンスを簡略化、認証処理の開発、テストも簡素化できます。高品質、安定稼働で安上がりです。業務サービス、企業向けクラウドの場合はこれが可能です。ちょっとしたことなのですが一考の価値ありです。
もう一つ。これはどうでしょう？
先に結論を言うとクロスサイトスクリプティングなので、そのままでは動きません（動いてはいけません）。サイトAのセッションの間にあるサイトBとのセッション（Javascriptで張られたセッション）が、サイトA以外にトークンを渡しうるからです。サイトCもしくは別のユーザーからこのトークンで認証要求されてもサイトAにはわかりません。なりすましでサイトAにログインできます。
postMessage による制限つきの処理も可能ではあるのですが、リダイレクションのような安全かつ一般的な手法を採用しない理由を説明できません。一見構成も簡単なのですが postMessage は特殊なケースに限定されると思います。
ITの世界は流行り、廃りが速いので変化にロバストであるよう、一般的な要素でシステムを構成、簡素化するよう心がけています。寿命の長いシステムはエンジニアの誇りです。ユースケースに応じた簡素な設計、費用対効果の高いシステムほど長持ちです。
永島志津夫
全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します）
