OAuth、SAML、OpenID Connect・・・これらの用語は聞いたことがあるし、いくつものブログで図解されている、認証の動きについても見てみた。各認証方式を使うメリットもわかる。
しかし、やっぱりやってみないとよくわからん。という人も結構いるのではないでしょうか。
ということで今回はMSが出しているクイックスタートを使ってOpenID Connect認証を行い、ASP.NET Core Webアプリへのログインまでの動きを見てみようと思います。

その際、ログインまでの通信も注視し、見えないところでどのようなやり取りが行われているのかを確かめ、なんとなくではなく、しっかりと認証の仕組みを理解していきたいと思います。

【クイックスタート】
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/quickstart-v2-aspnet-core-webapp

事前準備

　・Azureテナント
　・Visual Studio (事前に開発環境にインストールしておきます。)
　　※今回は2019を使用しています。

クイックスタートの実施

ではクイックスタートに従って、実施してみようと思います。

① Azure portal(https://portal.azure.com) にサインインします。

② [ホーム]-> [Azure AD Active Directory] -> [アプリの登録]を選択します。

③ [新規登録] をクリックします。




④ アプリケーション登録で下記項目を入力し、[登録]をクリックします。
（１） 名前：AspNetCore-Quickstart
（２） サポートされているアカントの種類：この組織ディレクトリのみに含まれるアカウント
（３） リダイレクトURL： https://localhost:44321/




⑤ [認証]を選択し、下記項目を入力のうえ、[保存]を選択する。
（１） リダイレクトURI：https://localhost:44321/signin-oidc
（２） ログアウトURL：https://localhost:44321/signout-oidc
（３） 暗黙の付与：IDトークン




⑥ [概要]を選択し、[アプリケーション (クライアント)]ID、[ディレクトリ (テナント) ID]をメモしておきます。




⑦ 以下クイックスタートの[コードサンプルをダウンロードします]からサンプルコードをダウンロードします。
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/quickstart-v2-aspnet-core-webapp




⑧ ダウンロードした[active-directory-aspnetcore-webapp-openidconnect-v2-aspnetcore2-2.zip]を展開し、
[active-directory-aspnetcore-webapp-openidconnect-v2-aspnetcore2-2]フォルダ以下を任意の場所に配置します。
※[c:\Azure-Samples]フォルダを作成し、配置しました。




⑨ [WebApp-OpenIDConnect-DotNet.sln]をVisual Studio 2019で開き、[appsettings.json]の以下を修正する。
（１） Domain：Azureテナントのドメイン名
（２） TenantId：⑥でメモした[ディレクトリ (テナント) ID]
（３） ClientId：⑥でメモした[アプリケーション (クライアント)]ID




⑩ Visual Studioからアプリを実行します。
　サインイン画面が表示されますので本アプリを登録したテナントのユーザID、パスを入力します。




⑪ アクセス許可の要求画面が表示されますので、[承諾]を選択します。




⑫ ログインできました。

【補足】

④で[この組織ディレクトリのみに含まれるアカウント]を選択したので、別のテナントのアカウントではログインできないのか試してみました。
　ア. Visual Studioからアプリを実行します。
　イ. 本アプリを登録したテナントとは別テナントのユーザID、パスを入力します。



　ウ.ログインできず、正常に認証が機能していることがわかりました。

通信の詳細を確認

ここからは通信を詳細に見てみようと思います。
通信はクイックスタートに記載の下図のようになっているのでしょうか。


https://docs.microsoft.com/ja-jp/azure/active-directory/develop/quickstart-v2-aspnet-core-webapp

事前準備

・WireShark (事前に開発環境にインストールしておきます。)
ダウンロード：https://www.wireshark.org/

通信内容の確認

WireSharkでパケットキャプチャを開始のうえ、⑩～⑫を実施します。
HttpProtocolで絞ると以下のようになりました。




１．No.48のパケットを見てみると、ブラウザからASPへGETリクエストが投げられていることがわかります。(図の①)




２．次に、No.55のパケットを見てみると、ASPからLocationの以下URLへリダイレクトされ、リダイレクト先へ認証リクエストを送っていることわかります。(図の②,③)
※このリダイレクト先はIdP(Identity Provider)の認証エンドポイントです。
リダイレクト先：https://login.microsoftonline.com/4ef04894-f0b0-47eb-8952-243fd9bff46b/oauth2/v2.0/authorize




Location部の内容を見ると、以下のようになっていました。



クエリ部分に注目すると、以下のようになります。

※パラメータの詳細は割愛します。以下を参照してください。
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/v2-oauth2-implicit-grant-flow

response_typeでid_tokenが指定されていることから、IDトークンを要求していることがわかります。
また、上述の通り以下にリダイレクトされます。
[https://login.microsoftonline.com/4ef04894-f0b0-47eb-8952-243fd9bff46b/oauth2/v2.0/authorize]
リダイレクト先はMicrosoftのサインページです。ユーザのサインインを行います。


３．サインインし、No.86のパケットを見てみると、IdPからIDトークンを取得できており、IDトークンをASPへ渡していることがわかります。(図の④,⑤)




Id_token部の内容を見ると、以下のようになっていました。(※一部加工)


このままでは何もわかりません。これはJSON Web Token(JWT)とよばれるもので、[.]で分割し、base64でデコードすると内容がわかります。
また、JWTは[ヘッダ].[ペイロード].[署名]という構成になっています。

ピリオドで分割してbase64デコードすると、以下のようになりました。(※一部加工)

※各クレームの内容については以下を参照してください。
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/id-tokens

これはresponse_typeがid_tokenの場合のフローです。他のtypeが指定されている場合はフローが異なります。
また、今回はIDトークンのみを取得していますが、アクセストークンを取得するパターンもあります。そちらはまた別の機会に検証しようと思います。

最後に

今回はOpenID Connect認証を使用したアプリへのログインの他、通信内容も見てみました。通信の内容を深堀りしていくと、認証の仕組みがよく分かると思います。
今後はOAuthでのアクセストークンの取得や認証、認可後に何ができるか、などの検証も行い、SSOやセキュリティの高い設計、また、アプリ開発における低コストな認証機能の実装に活かそうと考えています。

弊社ではMicrosoft Identity ManagerによるID統合管理を行っています。昨今Azure ADや3rdpartyのクラウド連携の案件も増えてきました。OAuth、SAML、OpenID ConnectはSSOソリューションでよく使われており、今後ID管理案件にも深く絡んでくると思います。
QESではこのような検証を行うことで、よりお客様のニーズに対応できる技術を身に付けております。

私共が提供するサービス・ソリューションにつきましてはこちらに掲載しております。
システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味を抱かれましたら、是非一度お問い合わせください。

このブログで参照されている、Microsoft、Windows、PowerApps、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。