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 reset their password or choose the answers to security questions, if the configuration allows.
When the user calls Next Identity Journeys via the
/personal-details endpoint, if the user already has an active session in the browser, the hosted service will display the personal details page. If the end user does not have an existing browser-based session, the login screen will be displayed to them before the personal details page is shown.
The contents of the personal details screen and the menu options are configurable. You can choose which fields will be displayed, or choose which menu options (for example, change password option, a two-factor authentication management option, or a sign-out option) will be available.
When configuring the personal details request, there is a set of required parameters described below. There are also additional parameters that can be part of the request, depending on the business rules.
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 &prompt=consent &access_type=offline &nonce=PYaFAdSRRtN3mi08Cc3luAWMPwCxJE9Kkb4c6XTw7WDE717RFi
In this example above, the base domain is
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.
The following parameters must be included on every request.
|Configures the URL the user is redirected after a successful authentication.|
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.
|The ID used to authenticate the API call.|
|Value that determines the authorization processing flow to be used, including what parameters are returned from the endpoints. The only acceptable parameter is: |
|OpenID Connect requests must contain the OpenID |
The following parameters are optional.
|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:|
The Authorization Server must not display any authentication or consent user interface pages. An error is returned if a user is not already authenticated or 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 as a method to check for existing authentication and/or consent.
The Authorization Server should prompt the user for reauthentication. If it cannot reauthenticate the user, it must return an error, typically
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.
|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 |
Updated 12 months ago