How to integrate the Next Identity Hosted Journeys end session workflow

Ending a user's session with the Next Identity Journeys is an optional workflow in your integration with Next Identity.

In this user journey, if you'd like to end the hosted session for a user outside of the hosted screens (for example, in tandem with a logout function in your own application) you can call this endpoint.

If this endpoint is called, the user will no longer have an active session on the hosted screens should they return to the /authorize endpoint.

Integration

The /endsession endpoint is designed to end the user session if one is present. It can then redirect the user based on the post_logout_redirect_uri parameter. This is the endpoint you would use if you were attempting to end the session outside of the Next Identity Journeys hosted screens. The endsession request consists of the base domain + the endpoint (/endsession) + parameters. Available parameters are listed below the example.

https://id.eu.nextreason.com/endsession?post_logout_redirect_uri=REDIRECT_URI&client_id=CLIENTID

Required Parameters

The following parameters must be included on every request.

ParameterDescription
post_logout_redirect_uriConfigures the URL the user is redirected to, after a successful endsession call.

Important note: this URL must be added to the allowed list of URLs for your integration. Please reach out to your Next Reason integration consultant to help with getting URLs added to this list.
client_idID used to authenticate the API call.

Optional Parameters

The following parameter may be included in the request.

ParameterDescription
stateThis state parameter is constructed by your application and included in the call to the hosted Next Identity service. It will remain unchanged and will be passed back to your application when the screen is redirected back. It is intended for use by your application to track user state. It should be an opaque value used to maintain state between the request and the callback.

Typically for applications, Cross-Site Request Forgery (CSRF, XSRF) mitigation is done by cryptographically binding the value of this parameter with a browser cookie. This value is required on every call, but the hosted service does not use this value in any way, it is solely for use by the application.

Doing so, the application can check and evaluate the value of the state parameter if it is correct or meets a specified criteria then perform expected actions or user journeys on the application-side.