inc/types/class-implicit.php:102 redirects to the client's callback with wp_safe_redirect() on the success path. There is no allowed_redirect_hosts filter registered anywhere in this plugin, so wp_validate_redirect() rejects any callback on a host other than the current site and silently falls back to admin_url().
This means the implicit grant likely can't complete for any client whose callback isn't on the same host as the WordPress install — which is the normal case.
The authorization_code grant's success path already gets this right at inc/types/class-authorization-code.php:166-167, using wp_redirect() with a phpcs:ignore WordPress.Security.SafeRedirect and a comment explaining why it's safe (the redirect URI has already been validated against the client's registration). Apply the same fix here.
Found while fixing the equivalent bug in the new PKCE error-redirect paths (inc/types/class-base.php, inc/types/class-authorization-code.php) on the add-pkce-support branch.
inc/types/class-implicit.php:102redirects to the client's callback withwp_safe_redirect()on the success path. There is noallowed_redirect_hostsfilter registered anywhere in this plugin, sowp_validate_redirect()rejects any callback on a host other than the current site and silently falls back toadmin_url().This means the implicit grant likely can't complete for any client whose callback isn't on the same host as the WordPress install — which is the normal case.
The
authorization_codegrant's success path already gets this right atinc/types/class-authorization-code.php:166-167, usingwp_redirect()with aphpcs:ignore WordPress.Security.SafeRedirectand a comment explaining why it's safe (the redirect URI has already been validated against the client's registration). Apply the same fix here.Found while fixing the equivalent bug in the new PKCE error-redirect paths (
inc/types/class-base.php,inc/types/class-authorization-code.php) on the add-pkce-support branch.