The HTTP Redirect binding uses a series of browser redirect URIs to exchange information. The following is a brief explanation of how this binding works.

1. The user visits the application, and the application determines that the user is not authenticated. The application generates an XML authentication request document and encodes it as a query parameter in a URI that is used to redirect to the Platform server. Depending on your settings, the application may also digitally sign this XML document and add this signature as a query parameter in the redirect URI to the Platform. This signature is used to validate the client that sent this request.
2. The browser is redirected to the Platform. The server extracts the XML authentication request document and verifies the digital signature, if required. Then, the user has to provide the credentials to be authenticated.
3. After authentication, the server generates an XML authentication response document. This document contains an SAML assertion that holds metadata about the user, such as the user's name, address, email, and any role mappings. This document is almost always digitally signed by using XML signatures and can also be encrypted.
4. Then, the XML authentication response document is encoded as a query parameter in a redirect URI that brings the browser back to the application. The digital signature is also included as a query parameter. The application receives the redirect URI, extracts the XML document, and verifies the realm’s signature to ensure that the authentication response is valid. Then, the information included in the SAML assertion is used to make access decisions or display user data.

The HTTP Redirect binding is used for the browser-based applications.

The HTTP POST binding works almost the same way as the HTTP Redirect binding, but instead of GET requests, XML documents are exchanged by POST requests. The HTTP POST binding applies to browser-based applications.

ECP (Enhanced Client or Proxy) is a SAML 2.0 profile that is used for exchanging SAML attributes outside the context of a web browser. The ECP binding is mostly used for REST or SOAP-based clients.

This is a browser-based protocol. We recommend using it to authenticate and authorize browser-based applications. With the authorization code flow, browser redirects are used to obtain an identity token and an access token.

1. A browser visits an application. The application notices that the user is not logged in and redirects the browser to Access Manager to be authenticated. The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect that Access Manager will use when it finishes authentication.

2. Access Manager authenticates the user and creates a one-time, very short lived, temporary code. Access Manager redirects back to the application by using the callback URL provided earlier. In addition, the temporary code is added as a query parameter in the callback URL.

3. The application extracts the temporary code and makes a background out of band REST invocation to Access Manager to exchange the code for an identity, access, and refresh token. After this temporary code has been used once to obtain the tokens, it can never be used again. This prevents potential replay attacks.

It is important to note that access tokens are usually short-lived and often expire after several minutes. The additional refresh token that is transmitted by the login protocol allows the application to obtain a new access token after it expires. This refresh protocol is important in the situation of a compromised system. If access tokens are short-lived, the whole system is only vulnerable to a stolen token for the lifetime of the access token. Future refresh token requests will fail if an admin has revoked access. This makes things more secure and more scalable.

Another important aspect of this flow is the concept of a public versus a confidential client. Confidential clients are required to provide a client secret when they exchange the temporary codes for tokens. Public clients are not required to provide this client secret. Public clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client. HTML5/JavaScript clients always have to be public clients because there is no way to transmit the client secret to them in a secure manner. Again, this is fine so long as you use HTTPS and strictly enforce redirect URI registration.

This is a browser-based protocol that is similar to the authorization code flow. The difference is that there are fewer requests and no refresh tokens involved. The drawback of this flow is the possibility of access tokens being leaked in the browser history because tokens are transmitted via redirect URIs. In addition, this flow does not provide the client with a refresh token, which means the access tokens should either be long-lived or users should reauthenticate when the tokens expire.

1. A browser visits an application. The application notices that the user is not logged in, so it redirects the browser to Access Manager to be authenticated. The application passes along a callback URL (a redirect URL) as a query parameter in this browser redirect that Access Manager will use when it finishes authentication.
2. Access Manager authenticates the user and creates an identity and access token. Access Manager redirects back to the application by using the callback URL provided earlier. In addition, the identity and access tokens are added as query parameters in the callback URL.
3. The application extracts the identity and access tokens from the callback URL.