This documentation provides information using redirect URI's with Entra ID Enterprise Applications. The intended audience is primarily campus IT staff and application owners.
When setting up Single Sign On (SSO) through Entra ID, if a user is not signed in, the client application will redirect the user's browser to Entra ID to do a username/password/MFA authentication and the Enterprise Application will then redirect the user back to the application they intended to access. The Enterprise Application needs to know what URLs are valid for the client application to do so. This is to avoid attacks there you embed malicious redirect URI's into an authentication link in order to harvest identity data or to deliver attack payloads. In the Shibboleth environment, this was an optional configuration that was enabled for a number of service providers. In Entra ID, it is a mandatory configuration.
As part of an SSO onboarding, OIT will ask for a list of redirect URI's for the application. This may be for multiple websites running on the same server, or even multiple environments running on multiple servers but that need the same configuration. There is a maximum of 256 redirect URI's that may exist on a single Enterprise Application.
It was plausible to do a full local development stack with Shibboleth because it was possible to turn off redirect URI validation, but even then was error prone and too complex for most people to succeed. With the move to Entra ID, OIT is not going to support that use case. For local application development, it is recommended to mock the authentication, assert the claims you expect to receive locally, and not actually go through the full auth flow. This will allow a single person to test multiple accounts/roles/groups simply by adjusting local configuration and it limits exposure of the client Id and secret, likely also making it less likely for it to be embedded it in containers or build processes. It also avoids the security concerns of having numerous different applications that all allow a localhost redirect URI, which makes it easier for local exploits to man-in-the-middle multiple apps.
It is technically possible, but not recommended to use a wildcard in a redirect URI. OIT will support them in very specific use cases. If there are a number of URI's that are programmatically constructed following a pattern within a fourth or fifth level domain name and are security-equivalent, it will be allowed. Some examples might include: