Start with the application's supported protocol
A request to enable SSO needs more than the staging website address. Determine whether the application supports SAML, OpenID Connect or another documented integration, and obtain its environment-specific configuration from the vendor or application owner.
SAML commonly exchanges assertions between an identity provider and a service provider. OpenID Connect provides authentication on top of OAuth 2.0 using identity tokens and related endpoints. These configurations use different identifiers and callbacks; substituting one protocol's field names for the other creates confusion.
For OIDC, Microsoft's protocol documentation explains the authentication role of the ID token. An ID token is not a general substitute for an API access token.
Collect the SAML values as exact strings
For a SAML application, collect the service provider's Identifier or Entity ID, assertion consumer service endpoint or Reply URL, sign-on URL if needed, and any required logout behavior. The Entity ID identifies the application; it is not necessarily a page a person can open.
Microsoft's SAML setup guide documents these fields, claims and signing-certificate configuration. Use the values the staging application expects, including paths and case where relevant.
Obtain the identity provider metadata and certificate information the application needs in return. Identify who installs that trust configuration and how certificate renewal will be handled. Configuring the identity provider is only one side of establishing the integration.
For OIDC, record the client and callback contract
An OIDC request should identify the tenant or authority, the application's client registration, supported account audience, redirect URI, required scopes and the application's token-validation expectations. Confirm the application's documented flow rather than inventing a redirect from its homepage.
The Microsoft redirect URI guide explains matching rules and platform-specific limitations. The redirect must agree with the application's callback and registration, including the intended path and hostname.
If a confidential server application needs credentials, identify the supported credential type and its secure provisioning owner. A native or browser client must not rely on a distributed client secret as though it were a confidential server. Keep secrets out of ticket bodies and ordinary screenshots.
Describe staging boundaries and account mapping
List the staging hostname, application instance and user group authorized to test. Explain whether staging has a separate identity configuration or shares one under the vendor's supported design. If temporary access is required, include its review date and the intended production transition.
Specify the identifier the application uses to locate a user: for example, a required NameID format or a particular claim. Confirm how that value maps to existing application accounts and what happens if an email address changes.
Document role claims and application authorization separately from authentication. Successful identity verification does not prove that the application assigned the correct role. Use an allowed test account and an account that should lack access to verify both sides.
Give IAM a request they can act on
A useful request contains the application name and owner, environment and purpose, protocol, vendor instructions, exact application identifiers and callback endpoints, requested test group, required claims and the application-side contact.
Add a compact acceptance statement: the permitted staging user can sign in, reach the intended application instance and receive the correct role; an unassigned user cannot receive access contrary to the agreed policy. Include who will validate those outcomes and how unexpected behavior will be reported.
For an illustrative staging portal at stage.portal.example.com, do not assume the callback is simply that host. Supply the vendor's exact callback path. Example hostnames in documentation are placeholders, not values to copy into a real registration.
Test beyond the Entra success screen
Follow sign-in through the application's final landing page and a permitted action. Check the issuer and application audience, callback handling, claim mapping and session behavior using the application's supported diagnostics.
A successful Entra sign-in log can coexist with an application rejection: the identity step completed, but the application may reject an unexpected audience, certificate, claim or callback. Preserve timestamps and correlation identifiers while protecting assertions and tokens as sensitive data.
Retest the actual production hostname and trust configuration during the production transition. A successful staging registration does not automatically establish the different endpoint's configuration. Record the final values and ownership so renewal and future changes have a clear starting point.
Connect SSO testing to the release plan.
Identity, DNS, certificates and application state all belong in the staging-to-production runbook.