Authorization provider
User registration works through an authorization provider. OneEntry does not create one by default when you create a project. If your project needs user registration, set up the authorization provider yourself.
Creating an authentication provider
To create an authentication provider, go to the users section and open the "Authentication Providers" subsection. In the provider creation form, specify:
- Name: a non-unique string. It can be in any format and is used only inside OneEntry. The name is how you tell providers apart, so choose names that are easy for you to work with.
- Type: how the data used to verify the user is delivered. Choose one from the list.
- email: the information that confirms the user's identity is sent to the email address they provide during registration.
- oauth: OAuth does not send codes to the user's contact details. Instead, it lets the user give your application limited access to their data on another service where they are already signed in (for example, Google, Apple, Yandex, or GitHub). Here is how verification works with Google: The user clicks "Sign in with Google" on your site. They are redirected to the Google sign-in page. The user enters their credentials (username and password) on Google's side, not in your application. This is more secure because you never handle their password. After a successful sign-in, Google asks the user whether they agree to share the requested data (for example, email and name) with your application. If the user agrees, Google redirects them back to your site with a special access token. Your project verifies this token and uses it to register or sign in the user automatically.
- Marker: a unique string. Use it to access the provider in your application's code. To avoid errors, take into account the syntax of the language your project is written in. For example, some languages don't allow dashes in variable names. In that case, use "my_provider" rather than "my-provide".
When all fields are filled in, click "Add" to create the authentication provider.
Configuring an authentication provider
To open the settings of an authentication provider, select it in the list and click the edit icon .
Basic settings
The provider editor has two tabs: Basic data and Version History.
In the settings, you can change the provider's name and marker. An authentication provider must have an authorization form. If you don't have a form of the "Sign In and Registration" type, create one (opens in a new tab). For the provider to work correctly, the form must contain a set of attributes (opens in a new tab) of the "User" type with at least three attributes: login, password, and verification information (email).
Even if you use the email address as the login, you still need to create both the "login" attribute and the "email" attribute.
If users have already registered through the provider, you can't change the form: the Form selection field is locked with the message "Form selection is disabled because there are users registered through this provider".
In the required Default User Group field, select the user group that users registered through this provider are added to.
For an oauth provider, select the service in the OAuth Provider field. The connection fields depend on the selected service; see the Google setup for an example.
To set up authorization and verification, follow these general steps:
- Create an attribute of the "Users" type with at least three fields: login, password, and verification information (email).
- Assign the appropriate roles to the attributes in the attribute settings.
- Create a form of the "Sign In and Registration" type and select the attribute set you created.
- Create an authentication provider and select the form you created.
Additional settings
This section contains user activation and token settings.
User activation is an extra registration step. If user activation is not enabled, every registered user is activated automatically.
Only activated users can use features that require authorization, such as placing an order or subscribing to events.
If you select "Activate new users via code", users are not activated automatically. Instead, the user receives a code through the method set in the provider, for example, by email. The user is activated only after confirming their email by entering the code.
Once a user enters their details and submits a registration request, they appear in the general user list, even if they are not activated yet. The "Number of days after which inactive users will be deleted" setting controls how long a user stays in this list if they don't confirm their email for any reason.
This section also contains the JWT token settings:
- Secret word for generating the JWT token: the word used as the encryption key for the token. A unique word is more secure.
- Authorization token lifetime (in seconds): how long the token passes validation. A shorter lifetime makes the user's connection more secure, but if it is too short, the user sends more requests to your project, which hurts performance.
- Refresh token life time (in seconds): how long the refresh token is valid. The application uses the refresh token to get a new authorization token without the user signing in again.
- System code lifetime (in seconds): once this time has passed since the code was sent to the user (for example, by email), the user can resend the code.
- System code length: the number of characters in the system code sent to the user.
- System code consists only of digits: when selected, the user receives a code made up of digits only. This makes authorization less reliable, but can be useful if, for example, the user can't switch to a Latin keyboard layout.
Deleting an authentication provider
You can delete a provider in Authentication Providers in the users menu. Select the provider in the list and click the delete icon .
You can't delete a provider that is already in use by any users: such providers have no delete icon in the list.