Profile
How to integrate the Next Identity Journeys profile workflow
User edit profile with the hosted screens is an optional workflow in your integration with Next Identity Journeys.
In this journey, a user with an active session can visit the edit profile screen. On this screen, an end user can update any allowed field (chosen by your application team). They can perform actions such as resetting their password or choosing the answers to security questions if the configuration allows.
When the user integrates Next Identity Journeys via /personal-details, if the user already has an active session in the browser, the profile screen will be displayed. If the end user does not have an existing browser-based session, the login screen will be displayed to them before the profile screen is shown.
Options
The options that appear on the customer's profile screen can be customized.
| Menu Option | Description |
|---|---|
| Personal details | Allows customers to update their personal details such as first name and last name. |
| Change password | Allows customers to update their current password with a new one. |
| Passwordless authentication | Allows customers to enable or disable authentication using fingerprint or face recognition. |
| Change security question & answer | Allows customers to select a new security question and update the answer. |
| 2-step verification | Only for applications that have two-step verification as optional; if two-step verification is required or is not available, the end user cannot modify it and wouldn’t have this menu option. |
| Sign out | Logs the customer out of the current session on the current devices. |
| Sign out of all devices | Logs the customer out of all sessions in all devices. |
Integration
The contents of the personal details screen and the menu options are configurable. You can choose which fields will be displayed or which menu options (for example, a change password option, a two-factor authentication management option, or a sign-out option) will be available.
A set of required parameters is described below when configuring the personal details request. Depending on the business rules, additional parameters can also be part of the request.
In the case of the personal details page, redirect_uri must now be on the allowlist. If it isn't, the user will be redirected to the app_link URL. This is a change from the previous behavior where any URL was allowed. Please be aware that this change could affect existing users using non-allowlisted URIs.
https://id.eu.nextreason.com/personal-details?
client_id=kmgzqcems552fk7pq7e3nw74u2wpu4a3
&redirect_uri=https%3A%2F%2Fappauth-js.dev.nextreason.cloud%2Fapp%2Fredirect.html
&response_type=code
&state=SWMsxiZSaa
&scope=openid
&access_type=offline
&nonce=PYaFAdSRRtN3mi08Cc3luAWMPwCxJE9Kkb4c6XTw7WDE717RFi
Base Domain
In this example above, the base domain is https://id.eu.nextreason.com/.
About base domains
Your base domain will be customized for your integration and for enterprise customers will be customized for your site name or brand name. If you don't know your base domain, please contact your Next Reason integration consultant.
Parameters
Required Parameters
The following parameters must be included in every request.
| Parameter | Description |
|---|---|
redirect_uri | Configures the URL the user is redirected to after successful authentication. Important note: This URL must now be on the approved allowlist for your integration. The user will be redirected to the app_link URL if the URL is not on the allowlist. Please reach out to your Next Reason integration consultant to help with getting URLs added to this list. Configures the URL the user is redirected to after successful authentication. |
client_id | The ID used to authenticate the API call. |
response_type | Value that determines the authorization processing flow to be used, including what parameters are returned from the endpoints. The only acceptable parameter is: code. |
scope | OpenID Connect requests must contain the OpenID scope value. If the OpenID scope value is not present, the behavior is entirely unspecified. Other scope values may be present. Scope values used that are not understood by an implementation should be ignored. The openid default value will be used if no specific scope value is known. |
Optional Parameters
The following parameters are optional.
| Parameter | Description |
|---|---|
prompt | Space delimited, case-sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are:noneThe Authorization Server must not display any authentication or consent user interface pages. An error is returned if a user is not authenticated, the client does not have pre-configured consent for the requested claims or does not fulfill other conditions for processing the request. This can be used to check for existing authentication and/or consent. loginThe Authorization Server should prompt the user for reauthentication. If it cannot reauthenticate the user, it must return an error, typically login_required. |
state | This 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 to maintain the 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 it in any way. It is solely for use by the application. By doing so, the application can check and evaluate the value of the state parameter to determine if it is correct or meets a specified criteria, then perform expected actions or user journeys on the application side. |
access_type | |
nonce | String value used to associate a client session with an ID token and to mitigate replay attacks. The value is passed through unmodified from the Authentication Request to the ID Token. Sufficient entropy must be present in the nonce values used to prevent attackers from guessing values. |
Updated 4 months ago