はじめに
OAuth 2.0 の認可レスポンスは、登録済みの『リダイレクト URI』宛に返却されます。詳細は『OAuth 2.0 の認可レスポンスとリダイレクトに関する説明』を参照してください。
複数のリダイレクト URI が登録されている場合、どのリダイレクト URI に認可レスポンスを返して欲しいかを、認可リクエスト時に指定する必要があります。この目的のために、redirect_uri リクエストパラメーターが用いられます。
認可サーバーは、redirect_uri リクエストパラメーターで指定された URI が、事前登録されたリダイレクト URI のいずれかに一致するかどうかを確認します。この「一致」について、「前方一致のサポートは可能か？」との質問を受けることが稀にあるので、見解を述べさせていただこうと思います。
OpenID Connect のケース
ID トークンを発行するなど、OpenID Connect の機能を使う場合、redirect_uri は登録済みのものと完全一致が要求されます。下記は OpenID Connect Core 1.0 / 3.1.2.1. Authentication Request にある redirect_uri リクエストパラメーターの説明からの抜粋です。
This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison).
「Simple String Comparison」が「単純な文字列比較による完全一致」を意味しています。
このように、OpenID Connect ではリダイレクト URI の前方一致の許容は仕様違反となるので、サポートできません。
Financial-grade API のケース
Financial-grade API / Part 1 / 5.2.2. Authorization Server / 10 に次のようにあります。
10. shall require the value of redirect_uri to exactly match one of the pre-registered redirect URIs;
簡潔な文ですが、「exactly match」という表現が「完全一致」を要求しています。このように、Financial-grade API ではリダイレクト URI の前方一致の許容は仕様違反となるので、サポートできません。
OAuth 2.0 のケース
OpenID Connect でも Financial-grade API でもない、純粋な OAuth 2.0 (RFC 6749) の場合、リダイレクト URI の比較には二つのケースがあります。
一つは、比較対象の登録済みリダイレクト URI が Full URI のケースで、このときは、OpenID Connect のときと同様、RFC 3986 / 6.2.1 Simple String Comparison による完全一致が要求されます。
もう一方は、比較対象の登録済みリダイレクト URI が Full URI ではないケースで、このときは、RFC 3986 / 6. Normalization and Comparison の規則に従って正規化 (Normalization) してから比較することなります。
いずれのケースにおいても、前方一致による比較はおこなわれません。
独自拡張
OAuth 2.0 (RFC 6749)、OpenID Connect、Financial-grade API のどの仕様を見ても、リダイレクト URI のチェックを前方一致でおこなうことを許容するようなことは書いてありません。そのような実装があるとすれば、それは独自拡張ということになります。
セキュリティ専門家の意見
『OAuth 2 in Action』の共著者の一人である Antonio Sanso は、2016 年 11 月 28 日に公開したブログ記事『All your Paypal OAuth tokens belong to me - localhost for the win』で次のように述べています。
The ONLY safe validation method for redirect_uri the authorization server should adopt is exact matching
Although other methods offer client developers desirable flexibility in managing their application’s deployment, they are exploitable.
つまり、**redirect_uri の確認方法で唯一安全な方法は「完全一致での比較」であり、サブドメインやサブディレクトリを許容するなどの他の方法（前方一致含む）は「便利かも知れないが悪用可能な脆弱性」**であると述べています。
結論
リダイレクト URI のチェックを前方一致でおこなう機能は、セキュリティ的に問題があるので、私が実装することは今後もありません。
もしあなたの認可サーバーの実装が前方一致を許容しているのであれば、PayPal 社が Antonio の指摘を受けてそうしたように、実装を修正することを強く推奨します。