Authorization Provider
The user registration mechanism is implemented through an authorization provider. An 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. It is used for operations within the OneEntry Platform. You will distinguish one provider from another by name, so name your authentication providers in a way that makes them easy for you to work with.
- Type - the type of data transmission used for user verification. It is selected from a list of options.
- email: information for confirming the user's identity will be sent to their email address, which they must provide during registration.
- oauth: OAuth does not send codes to the user's contact details. Instead, it allows the user to grant your application limited access to their data on another service that they have already authorized (e.g., Google, Facebook, VK, GitHub, Apple). Verification process using Google as an example: The user on your site clicks the "Log in with Google" button. They are redirected to the Google authorization page. The user enters their credentials (username/password) directly on Google's side, not your application. This enhances security since you do not handle their password. After a successful login, Google asks the user if they agree to provide your application with the requested data (e.g., email and name). If the user agrees, Google redirects them back to your site along with a special access token. Your project verifies this token and automatically registers or authenticates the user based on it.
- Token - a unique string type. It is used to access the provider within your application's code. Consider the syntax of the programming language your project is written in to avoid errors. For example, some languages may not support dashes in variable declarations. In such cases, it is better to specify "my_provider" instead of "my-provide".
After filling in all the fields, click the "Add" button to complete the authentication provider creation process.
Configuring the Authentication Provider
To access the settings of the authentication provider, select it from the list and click the edit icon .
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 one. For the provider to work correctly, the form must contain a set of attributes of type "User," which includes at least three attributes - username, password, and verification information (email).
Even if you use an email as a username, 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 "Users," which contains at least three fields - username, password, and verification information (email).
- Assign the appropriate 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 configurations for user and token activation.
User activation is an additional step in the registration process. If the user activation setting is not enabled, every registered user will be activated automatically.
Only activated users 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 enters their details and submits 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 configurations 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 duration for which the token will be validated. The shorter the time, the more secure the user's connection, but 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 the Authentication Provider
You can delete the authentication provider from the users menu.
Select the provider you want to delete from the list and click the delete icon .
If the provider is already being used by any users, it cannot be deleted.