OpenID Connect Discovery 1.0の周辺でハマったので、調べたときのメモとして残しておく。

OpenID Connect Discovery 1.0とはなにか

仕様は以下で定義されている。
OpenID Connect Discovery 1.0 incorporating errata set 2

概要

• RFC 5785で定義されているDiscoveryを、OpenID Connect向けに適用したもの。
• OpenID Connect Discovery 1.0を満たす場合、IssuerのURLが分かればメタデータへアクセスして必要な情報を取得することができる。

ID Tokenのiss Claimは、Issuerと一致する必要がある

3. OpenID Provider Metadataでは、issuerという項目について以下の記述がある。

issuer
REQUIRED. URL using the https scheme with no query or fragment components that the OP asserts as its Issuer Identifier. If Issuer discovery is supported (see Section 2), this value MUST be identical to the issuer value returned by WebFinger. This also MUST be identical to the iss Claim value in ID Tokens issued from this Issuer.

最後の一文が重要で、「Issuerによって発行されたID Tokenのiss Claimの値と一致する必要がある」とのこと。

Issuerに所定の文字列を連結すると、メタデータにアクセスできる必要がある

4. Obtaining OpenID Provider Configuration Informationには、以下の記述がある。

OpenID Providers supporting Discovery MUST make a JSON document available at the path formed by concatenating the string /.well-known/openid-configuration to the Issuer. The syntax and semantics of .well-known are defined in RFC 5785 [RFC5785] and apply to the Issuer value when it contains no path component. openid-configuration MUST point to a JSON document compliant with this specification and MUST be returned using the application/json content type. The openid-configuration endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) [CORS] and/or other methods as appropriate to enable JavaScript Clients and other Browser-Based Clients to access it.

DiscoveryをサポートするOpenID Providerは、Issuerの文字列に/.well-known/openid-configurationを結合したURLへアクセスすることでJSON形式のメタデータを取得できる旨が記述されている。

Azure AD B2CとOIDC Discoveryの関係

Azure AD B2CはデフォルトだとOIDC Discoveryをサポートしない

Azureが提供するAzure AD B2Cにおいては、どうやらデフォルトだとOpenID Connect Discovery 1.0非互換のようだ。
公式ドキュメントの互換性の記述は以下の通り。

[発行者 (iss) 要求] - このプロパティは、トークンを発行した Azure AD B2C テナントを識別します。 既定値は https:///{B2C tenant GUID}/v2.0/ です。 https:///tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ の値には、Azure AD B2C テナントと、トークン要求で使用されたユーザー フローの両方の ID が含まれています。 アプリケーションまたはライブラリで Azure AD B2C を OpenID Connect Discovery 1.0 仕様に準拠させる必要がある場合は、この値を使用します。

つまり、以下のことを示している。

• https://<domain>/{B2C tenant GUID}/v2.0/（規定値のiss）
  • https://<domain>/{B2C tenant GUID}/v2.0/.well-known/openid-configurationにメタデータは存在しない（＝OpenID Connect Discovery 1.0 をサポートしない）
• https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/
  • https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/.well-known/openid-configurationにメタデータが存在する （＝OpenID Connect Discovery 1.0 をサポートする）

デフォルトでDiscoveryをサポートしない動作になっている理由は明記されていないが、おそらくポリシー（ユーザーフローやカスタムポリシー）という概念の存在がこのようにさせていると考えられる。

Azure AD B2CのポリシーとOIDC Discoveryの関係

Azure AD B2Cのポリシー（ユーザーフローやカスタムポリシー）は、主に以下の目的で用いられると想定される。

• ユーザによって異なるログイン体験を提供するため（セキュリティを目的としない）
• セキュリティ強度を高めるため

前者の目的で利用する場合は、Issuerにポリシー名を含めないほうが運用しやすいはずだ。
なぜなら、Issuerを検証するときのURLパターンを複数定義することになるからだ。セキュリティを考慮しないのであれば、どのポリシーを用いたかを判別・検証できる必要はない。

しかし後者の目的で利用する場合は、Issuerにポリシー名を含めなければリスクが存在することになる。
例えばポリシーによってMFAを有効化にすることが可能であるが、認証時に用いたポリシー名をIssuerに含めなければ、どのセキュリティ水準でログインしたのかを判別・検証することができなくなる。その結果「MFAを必須とするアプリであるのに、MFAを必須としないポリシーで認証してアクセスする」という抜け道が存在し得ることになる。

これを踏まえると「Azure AD B2Cはポリシーによる柔軟なログイン体験を提供したが、それ故にOIDC Discoveryとの互換性が悩みの種になった」と考えられる。

Amazon API GatewayとOIDC Discoveryの関係

JWTオーソライザーはDiscoveryを満たす Providerしかサポートしない

JWTオーソライザーでは、1つ以上のClient IDと1つのIssuerを指定できるようになっている。
ここで指定するIssuerは、OpenID Connect DiscoveryをサポートするProviderであることが必須となっている。

AWSの公式ドキュメントJWT オーソライザーを使用した HTTP API へのアクセスの制御には、このような記述は見当たらない。
しかしIssuerとしてDiscoveryをサポートしないID Provider（Issuer+/.well-known/oidc-configurationのURLにメタデータが存在しない）を設定しようとした場合、当該URLが見当たらない旨のエラーが表示される。