Skip to main content

Authorization Provider

The user registration mechanism is implemented through the authorization provider. The authorization provider is not created by default when a project is created. If your project involves user registration, you need to set up the authorization provider yourself.

Creating an Authentication Provider​

To create an authentication provider, go to the users section, and then select the "Authentication Providers" subsection. In the provider creation form, you need to specify:

  • Name - a non-unique string type. The name can be in any format. The name is used for operation within OneEntry Headless CMS. You will distinguish one provider from another by name, so name your authentication providers in a way that makes it convenient for you to work with them.
  • Type - the type of data transmission used for user verification. Selected from a suggested list. For example, with the "email" type selected, the information for confirming the user's identity will be sent to their email, which they must provide during registration.
  • Token - a unique string type. Used to access the provider within your application's code. Consider the syntax of the language in which the project is written to avoid errors. For example, some languages may not support dashes in variable declarations. In such cases, it would be better to specify "my_provider" instead of "my-provide".

After filling in all the fields, click the "Add" button to complete the process of creating the authentication provider.

Configuring the Authentication Provider​

To go to the settings of the authentication provider, select it from the list and click on the edit icon Edit.

Basic Settings​

In the settings section, you can change the name and token of the provider. You must add an authorization form to the authentication provider. If you do not have a form of type "Login and Registration", you need to create it. For the provider to work correctly, the form must contain a set of attributes of type "User", which contains at least three attributes - login, password, verification information (email).

Important to Understand

Even if you use an email as a login, you still need to create both the "login" attribute and the "email" attribute.

The general sequence of actions for creating an authorization and verification system is as follows:

  • Create an attribute of type "For Users", which contains at least three fields - login, password, verification information (email).
  • Assign the corresponding roles to the attributes in the attribute settings.
  • Create a form of type "Login and Registration", specifying the created set of attributes.
  • Create an authentication provider, specifying the created form.

Additional Settings​

The additional settings section contains settings for user and token activation.

User activation is an additional step in registration. If the user activation setting is not enabled, every registered user will be activated automatically.

Functions for Authorized Users

Only an activated user can interact with system functions that require authorization. For example, creating an order or subscribing to events.

If you set the flag "Activate new users via code", users will not be activated automatically. Instead, a code will be sent to the user in the manner specified in the provider, for example, via email. Such a user will be activated only after confirming their email by entering the code.

After the user has entered their data and submitted a registration request, they will appear in the general user list, even if they are not activated. The setting "Number of days after which inactive users will be deleted" determines how long a user will remain on this list if they do not confirm their email for any reason.

The additional settings block contains settings for JWT tokens.

  • Secret word for generating the JWT token - a word that serves as the encryption key for the token. A unique word provides greater security.
  • Token lifetime (in seconds) - The time during which the token will be validated. The shorter the time, the more secure the user's connection, however, too short a time will increase the number of requests from the user to your project, negatively affecting performance.
  • System code lifetime (in seconds) - After this time has elapsed since the code was sent to the user (e.g., via email), the user will be able to resend the code.
  • Length of the system code - The number of characters contained in the system code sent to the user.
  • System code consists only of digits - a flag that, when set, will cause the user to receive a code consisting only of digits. This reduces the reliability of authorization but may be convenient if, for example, the user does not have access to a layout with Latin characters.

Deleting an Authentication Provider​

You can delete a provider from the authentication providers menu in the users section. Select the provider you want to delete from the list and click on the delete icon Edit.

Important to Understand

If the provider is already being used by any users, it cannot be deleted.