OPTIONAL. Informs the Authorization Server of the mechanism to be used for returning parameters from the Authorization Endpoint. This use of this parameter is NOT RECOMMENDED when the Response Mode that would be requested is the default mode specified for the Response Type.
まぁ、元々はOAuth2.0のレスポンスの定義なので、こちらの仕様をみる方が適切といえそうです。
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#ResponseModes
OPTIONAL. Informs the Authorization Server of the mechanism to be used for returning Authorization Response parameters from the Authorization Endpoint. This use of this parameter is NOT RECOMMENDED with a value that specifies the same Response Mode as the default Response Mode for the Response Type used.
このOAuth2.0の仕様が発行されたのが2014年なのでその時点ではqueryとfragmentの2種類だけが本文には記載されており、追加モードとして今回の主役であるform_postの定義への参照が記載されています。
と、ここでちょっと待て、、と。
上記を見るとresponse_typeのデフォルトのresponse_modeの値を取る場合以外はこのパラメータを使うことは推奨しない、と明確に書いてありますね。
ということは、Azure AD B2Cが外部IdPと連携する際にresponse_typeの値に関わらずresponse_modeを必ず指定するのは推奨外の動作ってことですよね。。
また、先日書いたEntra IDの外部認証プロバイダ連携の場合はresponse_type=id_tokenでリクエストがされ、かつ外部認証プロバイダからはform_postでレスポンスが返されることを期待するにも関わらずresponse_modeが指定されないのはどうなんだ、、、という話です。（というか世の中にあるIdP製品やサービスでresponse_type=id_tokenだけをリクエストされてform_postでレスポンスするものは存在しないと思います）
この辺はMicrosoftさんちゃんと仕様を見ようよ・・・って思いますね。。
ちなみにresponse_type=id_tokenの場合のデフォルトのresponse_modeはfragmentです。（こちらに定義されています）
https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#id_token
The default Response Mode for this Response Type is the fragment encoding and the query encoding MUST NOT be used.
気を取り直してresponse_mode=form_postの話に戻ります。response_modeは認可サーバからの認可レスポンスを返却するための方式を示すパラメータであることはわかりましたが、値にform_postが指定するというのはどう言うことなのか、についてはこちらの追加仕様に記載されています。
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Abstractにこう記載されています。
This specification defines the Form Post Response Mode. In this mode, Authorization Response parameters are encoded as HTML form values that are auto-submitted in the User Agent, and thus are transmitted via the HTTP POST method to the Client, with the result parameters being encoded in the body using the application/x-www-form-urlencoded format.
まぁ、要するにHTML formにresponse情報を入れてredirect_uriにPOSTしますよ、ってことです。ws-federationやSAMLのHTTP POST Bindingですね。
ここでも話は横にそれますが、今でこそOAuth2.0やOpenID Connectは認可コードをリライングパーティに発行し、リライングパーティは認可サーバのTokenエンドポイントへ投げ込んでaccess_tokenやid_tokenを受け取る、いわゆるresponse_type=codeのコードフローが主流になっていますが、SAMLも当初はHTTP POSTやRedirect BindingではなくArtifact Bindingが主に使われていた時代がありました。当時はフィーチャーフォンのブラウザなど扱えるURL長に制限があったり、フロントに大きなPOSTデータを持ってくると通信量が増えてパフォーマンスに大きく影響が出るなどの問題があり、ArtifactといわれるコードをService Providerへ提供、Service ProviderがIdentity ProviderへSAMLトークンをとりにいく、という流れが必要だったためです。当時と今では事情がことなりますが、認可コードフローとのままですね。なんといってもOpenID Connectは、開発中はOpenID ABC（Artifact Binding and Connect）って名前でしたし、OpenID Connect Coreの定義をしている、OpenID FoundationのAB/ConnectワーキンググループはArtifact Binding Working GroupとConnect Working Groupから組成されており、ABはArtifact Bindingなわけです。
話を戻すと、Entra IDの外部認証プロバイダの際にも書いた通り、id_tokenとstateをformに乗せてPOSTしてあげるためのHTMLをレンダリングするコードを書けば良いってことになります。
node_expressとejsで書くとこんな感じです。
レンダリングされるhtmlテンプレートはこんな感じですね。（前回の記事では動きを見るために自動POSTしていませんでしたが、今回はJavaScriptで自動POSTする形にしています）
しかし、form_postを使っているのって実態としてMicrosoftくらいしかいないんですよね・・・（Sign In with Appleも使ってたかも）
現状、ブラウザを経由してトークンのやり取りをする、つまりArtifactや認可コードを使わないパターンを使いたい大きな理由は先ほど挙げたフィーチャーフォンのブラウザの制限や通信速度・通信量の問題というよりも、エンタープライズなどIdPがファイアウォールの内側にありリライングパーティが外側にあるというケースやWalletがIdPになるケースなど、IdPが外部からのアクセスできない（Walletの場合はエンドポイントを持たない）という問題である場合が多いと思います。
その場合は当然Implicitを使う、つまりフラグメントにトークンを入れてJSでリライングパーティへ渡す、というやり方になるわけですが、これだとリライングパーティのredirect_uriがブラウザ上でJSをハンドリングする機能を実装することが前提になってしまいます。もちろんこれができるケースならば良いのですが、リライングパーティ向けの共通ライブラリを提供しようとすると単純にバックエンドでPOSTを受け取るAPIを作っておく方が楽なんじゃないかと思います。さらに言うと、これまでws-federationやSAMLのSP向けのライブラリを提供してきたベンダであれば少しパラメータを変えれば対応できると言う意味でform_postの方がありがたかった、と言うのが実情だったんだろうなぁ、、と聞いた話から推測しています（あくまで推測です）。まぁ、SameSiteの問題もあったりしますがこの辺は各社対応してきているので現状は大丈夫だと思いますが。
ということで、今回はresponse_modeとform_postの話をしましたが、みなさんが作るIDシステムやアプリケーションのシステム配置や要件によって適切な実装をしていきましょう。
こんにちは、富士榮です。
ようやくこのシリーズも終わりです。
引き続き攻撃パターンと緩和策です。最後の3つを読んでいきます。
- HTTP/1.1 200 OK
- Content-Security-Policy: frame-ancestors https://ext.example.org:8000
- Content-Security-Policy: script-src 'self'
- X-Frame-Options: ALLOW-FROM https://ext.example.org:8000
- window.opener.postMessage(
- {
- code: "ABC",
- state: "123"
- },
- "*" // any website in the opener window can receive the message
- )
- window.opener.postMessage(
- {
- code: "ABC",
- state: "123"
- },
- "https://client.example" // use explicit client origin
- )
- window.addEventListener("message", (e) => {
- // validate exact authorization server origin
- if (e.origin === "https://honest.as.example") {
- // process e.data.code and e.data.state
- }
- })
こんにちは、富士榮です。
すこし空きましたがこちらも続けていきます。
引き続き攻撃パターンと緩和策です。前回は307リダイレクトまで行きましたので続き13個目/18個のTLSを終端するリバースプロキシから行きたいと思います。
こんにちは、富士榮です。
IETF 119がブリスベンで本日まで開催されています。
実は私はIETFは参加したことがない（昨年の横浜も忙しくて行けなかった・・・）のですが、参加している人たちから色々と情報が流れてきています。
Mike Jonesさんが以下のポストをしています。
Eight Specifications Published in Preparation for IETF 119
ポストによると主にMikeが絡んでいるスペック中心ではありますが、以下のスペックに関するUpdateがあったとのことです。
こんにちは、富士榮です。
すこし空きましたがこちらも続けていきます。
引き続き攻撃パターンと緩和策です。前回はリソースサーバでのアクセストークンの漏洩まで行きましたので続き10個目/18個の盗まれたアクセストークンの悪用から行きたいと思います。
こんにちは、富士榮です。
すこし空きましたがこちらも続けていきます。
引き続き攻撃パターンと緩和策です。前回はアクセストークンインジェクションまで行きましたので続き７個目/18個のクロスサイトリクエストの偽造から行きたいと思います。
こんにちは、富士榮です。
前回、前々回とOAuth2.0 Security Best Current Practiceについてみてきました。
今回は攻撃パターンと緩和策についてみていきます。18パターンも定義されているので今回は最初の3つを紹介していきます。
こんにちは、富士榮です。
前回に続き、OAuth2.0 Security Best Current Practiceを読んでいきます。
今回は2つ目のブロックである「攻撃モデルの更新」です。今回は短めです。
こんにちは、富士榮です。
先週は色々と仕様のアップデートが動いた週でした。
OAuth 2.0 Security Best Current Practice（OAuth2.0 BCP）
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics
OAuth 2.0を実装する際のセキュリティに関するベストプラクティスに関するドキュメントです。（そのまま）
OpenID for Verifiable Credential Issuance
こちらは言わずと知れたVerifiable CredentialをOpenIDプロトコルに乗せて発行するための仕様ですね。Verifiable Presentationに関する仕様はすでにImplementers Draft 2まで出ていますが、発行側は初のImplementers Draftですね。ようやく実装者は本気で実装が開始できる段階まで来ている、ということです。
それぞれの細かい内容はおって紹介したいと思います。
こんにちは、富士榮です。
噂のデジタル認証アプリですが、パブコメが出てますね。
電子署名等に係る地方公共団体情報システム機構の認証業務に関する法律施行規則の一部を改正する命令案に対する意見募集について
https://public-comment.e-gov.go.jp/servlet/Public?CLASSNAME=PCMMSTDETAIL&id=290310311&Mode=0
2月末までの募集のようなのでぜひ皆さんみておくと良いと思います。
ざっくり見てみたいと思います。色々と課題もありそうです・・・
OpenID Connect/OAuth2.0もちゃんと採用されていますね。
こんにちは、富士榮です。
Sign in with SlackがOpenID Connectに対応したので、Azure AD B2Cに繋いでみました。
Slackのドキュメントはこちら
ふむふむ。昔のSlack連携はOAuth2.0でidentity.*というスコープが使われていたところがOpenID Connectに対応したってことですね。
ではやってみましょう。
こちらからSlackアプリ定義を作ります。メインはAzure AD B2C（今回のケースだとRelying Partyになります）に渡すためのclient_id、client_secretを作るための行為です。
Create an Appをクリックするとスクラッチから作るかapp manifestを使って作るかを聞かれますので、今回はスクラッチから作ることにします。
https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp
これでSlack側への設定は終わりです。
左のナビゲーションメニューのBasic Informationからclient_id、client_secretが取得できるのでメモしておきましょう。後でAzure AD B2C側に設定します。
次はAzure AD B2C側です。
IDプロバイダのメニューから新しいOpenID Connectプロバイダーをクリックして設定を開始します。
必要なのは以下の設定です。
こんにちは、富士榮です。
ついに発売されました。米OpenID Foundation理事長の崎村夏彦さんによるデジタルアイデンティティに関する集大成とも言える書籍、その名も「デジタルアイデンティティー 経営者が知らないサイバービジネスの核心」です。
献本いただきましたので早速熟読してみました。
ここまで体系的かつ広い視点でデジタルアイデンティティに関して俯瞰した書籍は洋書を含めて存在していなかったんじゃないか？と思います。（Phil Windleyの「Digital Identity」はもちろん良書ですが、如何せん2004年の書籍なので古くなってきています）
とにかくこちらから購入できるので、まだの人は今すぐポチるのです。
ざっと感想を含め見どころを。
書き始めるとキリがないので、この辺りでやめておきます。
また、大きな特徴として「他の文献への参照が異常に少ない」という点が挙げられると思います。これは常に第一線でデジタルアイデンティティに取り組んでこられた崎村さん自身が執筆している、ということが大きく影響していると思われます。つまり、本書は今後の文献では一次ソースとして扱われることになる、ということを示しています。その点においても必携・必読であるとも言えます。
ちなみに、OpenIDファウンデーション・ジャパンでは崎村さんをお招きして本書の見所解説などを直接お話しいただく出版記念イベントを企画している最中です。こちらは纏まりましたら改めてお知らせしたいと思います。（サインもらえるかも！）
投稿
すべてのコメント
