Register

Enable new users to create their own accounts

🚧

Deprecation Notice

The content on this page has been deprecated and is no longer valid. We have made significant improvements and updates to provide you with the most accurate and up-to-date information.

To access the latest content, please visit: Register.

With user self-registration with Next Identity Journeys the end user will be presented with a screen asking for a set of fields to create an account (such as email address, first name, and password).

This workflow, like most others in the hosted Next Identity service, begins with your application directing users to the /authorize endpoint.

With active session in the browser

When the end user makes a request to Next Identity Journeys via the /authorize endpoint, the hosted screen will not present the registration screen if the user already has an active session in the browser. Instead, the end user will be immediately redirected back to the application with an authorization code.

Without an active session in the browser

If the end user does not have an existing browser-based session, the login screen will be displayed. On this login screen, if your application has been configured to allow self-registration, the user will be shown the option to create a new account.

The only action the application needs to take to begin this journey is to call the /authorize endpoint.

Integration

When configuring the authorization request there is a set of required parameters described in the table below. There are also additional parameters that can be part of the request, depending on the business rules.

https://id.eu.nextreason.com/
authorize?
redirect_uri=https%3A%2F%2Fappauth-js.dev.nextreason.cloud%2Fapp%2Fredirect.html
&client_id=pnxf3up7tae8mbhzb9dbpbcmfbx32qjp
&response_type=code
&state=SWMsxiZSaa
&scope=openid
&prompt=consent
&nonce=ztUpfEKkX7HcpASapzJDSFsBoFBbvRkNdDGEVj5TDrG58e7MwS
&ui_locales=en-US
&code_challenge=Pr5KkBc1CqsjVH5Izsx-CXu1HEOrtNLBPJU20-MMGWw
&code_challenge_method=S256

Base Domain

In the 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.

Endpoint

To check if the user is signed in, you will first verify if an active session is already present in the browser. The endpoint to use for this is /authorize.

Parameters

Below are the required and optional parameters for the /authorize endpoint. Your specific parameters may vary depending on your configuration; if you're unclear on the parameters to use, please contact your Next Reason integration consultant.

Required Parameters

The following parameters must be included on every /authorize request.

ParameterDescription
redirect_uriConfigures the URL the user is redirected to, after a successful authentication.

Important note: This URL must be included in the safelist configuration. Contact your Next Reason integration consultant to add URLs to this list.
client_idThe ID used to authenticate the API call. This client ID is tied to your specific configurations and rules. Contact your Next Reason integration consultant if you do not know your client ID.
response_typeValue that determines the authorization processing flow to be used, including what parameters are returned from the endpoints.

The only acceptable parameter is: code.
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.
scopeOpenID 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.

ParameterDescription
promptSpace 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:

none
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.

login
The Authorization Server should prompt the user for reauthentication. If it cannot reauthenticate the user, it must return an error, typically login_required.

consent
nonceString 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.
ui_localesSets the language to be displayed in the screen. Session cookie will save the locale setting sent for the first time, if this parameter is not present the latest language saved will be used to display the screen. It allows multiple locales and in case there's no configuration for the first one, it searches for the second one and so on.
Since the ui_locales parameter is optional and will use the default_locale on settings if no value is present.

See Localization for list of supported locales and the accepted values.
code_challengeUsed in PKCE protocol.
code_challenge_methodUsed in PKCE protocol.
login_hintIf this parameter value is passed with the call to the /authorize or /register endpoints, the username field on the hosted screen will be pre-filled. This applies for email address or mobile phone number.