こんにちは、富士榮です。
OpenID Connectってシンプルなプロトコルだと思いますが、やっぱりOpenID Providerの気持ちにならないと本当のところはわからないよね、ということで「OpenID Providerを作る」シリーズ（デ⚫︎ゴ⚫︎ティーニ風）でもやってみようかと思います。
超絶ベーシックなところまでは前回・前々回のポストを踏まえて2時間くらいで作ってみたのでまずはこちらを解説しつつ実装を一緒に育てていきたいな、と考えています。
とりあえず作ったところまではこちらのレポジトリで公開しています。（前回のポストからの追加部分としては認可コードをJWEにしたところくらいです。詳しくはReadmeを見てください）
https://github.com/fujie/oidc-study-op
ということで、中身は次回から解説しますが現状の実装で何ができるのかの確認を兼ねてOpenID Connectの通信が実際にどうなっているのかを、Azure AD B2Cを使って確認してみようと思います。結構Azure AD B2CとかAuth0を触るときにサービス側が外部IdPにどういう期待をしているのかを知るためにこれまでも簡易IdPを作って通信トレースをとったりしていたのですが、この辺りの試行錯誤がOpenID Connectそのものを知ることにつながりますし、Azure AD B2CやAuth0などのIDaaSについての知識も深められて一石二鳥です。
早速Azure AD B2Cに作ったOpenID ProviderをIDプロバイダとして読み込ませてみます。作ったOpenID Providerはローカルで動かしていますのでngrokを使ってインターネットからアクセスできる様にしています。
ちなみにAzure AD B2Cに限らずMicrosoftのID基盤はresponse_modeとしてform_postをデフォルトにしているのですが、そんなものは作っていないのでqueryに変更してあげる必要があります。
free版のngrokを使っているのでngrokを止めてしまうとURLが変更されてしまうので注意が必要です。（もし止めてしまったら一度IDプロバイダを消して再作成する必要があります）
なお、ngrokを使う利点としてインスペクションができることです。（http://127.0.0.1:4040をブラウザで開くと通信内容がトレースできます）
Azure AD B2CでIDプロバイダの設定をして保存を行うとDiscoveryとjwks_uriへのアクセスがあります。
この状態でユーザーフローを作成し、実行してみます。
順調にIDトークンが発行され、ユーザ登録画面に遷移しました。
インスペクションを見るとOpenID Connectのフローに則って順次アクセスされていることがわかります。
0 件のコメント:
コメントを投稿