It is common (and easiest) for all authentication requests to contain two redirect URLs:
- One (often known as the reply URL) that is passed in the "redirect_uri" parameter, which must be registered with Azure AD B2C, to which all authentication responses are returned from Azure AD B2C to the relying party application. An example of this is
https://www.myawesomesite.com/oidc-signin
.
- Another (often known as the return URL) that is round-tripped in the "state" parameter, which doesn't have to be registered with Azure AD B2C, to which the end user is returned after the relying party application has handled the authentication response. An example of this is
https://www.myawesomesite.com/games/fungame/points
.
An authentication handler, such as the ASP.NET Core authentication middleware, manages these redirect URLs for you.
For instance, when the authentication handler creates the authentication request, it encodes the currently protected URL (e.g. https://www.myawesomesite.com/games/fungame/points
) in the "state" request parameter.
To ensure this URL isn't tampered with, the "state" parameter should be protected, using encryption or signing.
When the authentication handler processes the authentication response, assuming it is a successful response, it creates an identity cookie and redirects the end user from https://www.myawesomesite.com/oidc-signin
to the originally protected URL in the "state" response parameter.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…