Request Orchestration Tokens
Request orchestration tokens allow clients to delegate authentication to another first-party identity client of the same account.
This is done by serializing the request into an opaque token that is included as a query parameter in the login URL of your choice. Our web core/UI SDKs will then automatically detect the token and include it when authenticating end-users.
|
Orchestrated flows are supported from version |
-
A client application performs an authentication request.
-
The authorization server assesses the user’s SSO session.
-
In the absence of an SSO session, users are redirected to the configured login page operated by another identity client.
-
Following user authentication, the underlying request is resumed.
-
-
An authorization code is issued for the client.
| Steps 4-5 represent your typical session management in which the authorization code or refresh token are exchanged for a set of fresh tokens. |
Instructions
To enable the request orchestration for your client:
-
Go to your desired first-party identity client in your ReachFive Console. Or create a new one.
-
Scroll down to Login URL.
-
Enter a Login URL.
-
Enable the Attach orchestration token option. This token is detected by the web SDKs and is automatically included in authentication flows.
Example
You have a centralized login web page that you wish to use for all of your applications (including native apps). Using the iOS or Android SDKs, you may authenticate end-users through that page by calling the:
-
loginWithWeb method.
-
webviewLogin method.
| If end-users already have a valid SSO session, they will be immediately redirected to your app with an authorization code. |
MFA passwordless flow with orchestration tokens
When finalizing an orchestrated MFA flow, the application must redirect the user using a GET passwordless/verify request, ensuring the orchestration token is included in the call.
This is what successfully resumes the underlying authentication request.
Best Practice
The redirect via GET passwordless/verify should only happen after the code is proven valid.
Using our SDKs, verifyPasswordless silently tests the verification code before the final redirect.
If the code is invalid, the user should remain on the current page to try again. Only after 3 invalid attempts should a maximum attempts error be returned on the same page.
| For detailed implementation steps, see the Handling orchestrated MFA flows section in the MFA documentation. |
