To direct back to your signing applications multiple redirect_uri can be whitelisted on your connection to MAB. For security reasons we only allow unique domain entries without the use of asterisk.
Understanding the Role of redirect_uri in OIDC:
In OpenID Connect (OIDC), the redirect_uri is a critical security component. It defines where the Identity Provider (IdP) should send the authentication response (including the authorization code or tokens) after a user successfully logs in. This URI must exactly match one of the URIs registered or whitelisted with the IdP during client registration.
If redirect_uris are not properly protected or validated, it opens up several attack vectors, which can compromise user authentication and lead to serious security breaches.
Attack Vectors on Unprotected redirect_uri:
Open Redirect / Redirect URI Manipulation
Description:
If an attacker can manipulate the redirect_uri parameter to point to a domain under their control (e.g., via a wildcard or weak domain matching rule), the IdP might unwittingly send the authentication response (e.g., an authorization code or ID token) to that malicious site.
Impact:
The attacker can capture the code or token and use it to impersonate the user or gain unauthorized access.
Example:
Suppose the IdP allows:
If the IdP doesn't enforce strict matching, it could mistakenly send the code to this malicious domain.
Subdomain Takeover
Description:
Even when redirect_uri is limited to specific subdomains (e.g., app.example.com), if one of these subdomains is improperly managed (e.g., DNS exists but hosting is misconfigured), an attacker could take it over.
Impact:
Once the attacker controls the subdomain, they can intercept tokens sent to it, effectively hijacking sessions.
Example:
redirect_uri=https://staging.example.com/callback
The staging subdomain is no longer used and its hosting is released. An attacker sets up a server at that domain and captures tokens.
Mix-Up Attacks
Description:
Occurs when multiple IdPs are involved. If the relying party (RP) cannot correctly bind the response to the initiating IdP, an attacker could confuse the RP into accepting tokens from a different IdP.
Impact:
Tokens intended for one client could be mistakenly accepted by another, causing session confusion or unauthorized access.
Note:
This risk increases if the RP uses dynamic redirect_uris without strict validation.
Phishing via Open Redirect
Description:
An attacker could trick users into authenticating through the legitimate IdP, but using a redirect_uri that leads to a phishing page which mimics the legitimate app.
Impact:
After login, users are redirected to a lookalike site where they might enter sensitive data.
Example:
redirect_uri=https://legitapp.com/redirect?target=https://attacker.com/fake-page
The IdP sees the legitimate redirect_uri, but after redirection, the user ends up on a phishing site via target.