In this paperwork service for authentication, authorization, and user management has been designed and developed. The purpose of this work is to simplify the configuration of user security in web and mobile applications with a ready-made solution. The service can be implemented as a separate server on the Internet-you will be able to use it right after registering a client this method does not require the use of your resources, but it is less secure, especially for applications that keep vulnerable data. Still, the best and the most secure option is to download the source code and run the service on the local network. In this case, it will be only accessible to other applications or microservices in the case of microservice architecture.
With the rapid development of information technology even traditional things such as shopping, going to restaurants, or going to work have become available online. It is enough to have access to the Internet on your mobile phone, computer, or tablet [1]. Then you can make purchases online, read the news on a reliable website, do all the work on a laptop, and even organize a meeting with colleagues, etc. There are plenty of examples of how digitization facilitates many processes in different areas of our lives, but it also challenges the security of customers and service providers [2].
Nowadays, most web and mobile applications require the implementation of user accounting, authentication, and authorization tools [3]. In most cases, this functionality will be the same and when you are developing a new application, you’ll need to do this all over again. Based on this, you can automate this process and save money and time on creating something that has already been created more than once [4].
The main goal of this paper is to create a
service for the authentication, authorization,
and accounting of users [5] to reduce the time
for the development of such functionality and
simplify the existing application. The solution
can be integrated with other applications in
two different ways:
• As a third-party service that is located on
a separate server that accepts requests
via the Internet.
• As an embedded service in your internal
network which accepts the requests
from the internal intranet network [
Developers looking to streamline logins or
Identity and Access Management (IAM) in their
apps have many mechanisms available to them
[
OpenID and OAuth provide authentication
and authorization, respectively. While OAuth
offers a foundation of authorization, it doesn’t
concern itself with authentication at all.
OpenID picks up where OAuth leaves off,
adding authentication functionalities to your
application [
OpenID Connect (OIDC) is an authentication
protocol i.e. an identity layer built upon OAuth
2.0 [
Open Authorization (OAuth) is a method for authorizing access between apps. It enables a secondary application to access and perform certain functions within your app. By generating access tokens from the secondary app or website, it offloads the work of authentication and simply grants access.
The way OAuth works is similar to OIDC at
a surface level. It allows for communication
between two apps or websites. Where it differs
from OIDC is in its lack of authentication of the
user [
OAuth provides a foundation in
authorization, allowing other apps to access
yours. And OpenID builds upon that, adding the
ability to authenticate user identities.
Together, they make all elements of login and
IAM much simpler and safer on the user side.
Both OIDC and OAuth offer benefits in a wide
variety of use cases, and many apps implement
both of them [
The main difference between OAuth2 and
OpenID Connect is that OAuth2 is only
concerned with authorization, while OpenID
Connect is also concerned with authentication.
Authorization means granting access to
resources, while authentication means
verifying the identity of a user [
The problem is that both protocols can be used
to accomplish similar tasks, but that doesn’t
mean they should be used interchangeably.
OpenID provides an identity assertion while
OAuth is more generic. When a client uses
OAuth, a server issues an access token to a third
party, the token is used to access a protected
resource, and the source validates the token
[
You can think of a token issued by a resource
server like it’s a ticket to a movie. Nowhere on
the ticket does it say any identifying information
about an individual, it simply is used as a way of
saying I have permission to enter. This means
that the issued token may be in the hands of a
bad actor or a machine [
That is why the service offered below allows you to implement authentication and authorization mechanisms at the same time.
and Accounting of Users
At a conceptual level, authentication
vulnerabilities are among the most
understandable, but they can cause some of the
most critical damage because of the obvious
connection between authentication and
security. Most authentication threats are
associated with passwords or password-based
authentication methods. But broken
authentication is also the cause of many
vulnerabilities [
Common broken authentication-related vulnerabilities: • Vulnerable authentication logic. • Weak user profile or password recovery process. • Vulnerable library usage for authentication. • Unsecured session. • No blocking and no limit on the number of login attempts.
• Insecure password verification methods. • Weak password security policies.
The suggested authentication mechanism
provides several possibilities at once, which
allows for to minimization of the occurrence of
typical vulnerabilities and also allows to
implementation of the least privileges
principle [
Using a password, confirmation with a code via an email address, and confirmation with a code via a phone number (Fig. 2).
Password reset. To use this feature, you need to have a verified email address or phone number. In this case, a pseudo-random password is generated and sent to a verified phone number or mailbox. It is worth noting that the temporary password is valid only for a short period after which if the password has not been changed the procedure must be repeated (Fig. 3).
Users profile block. This feature is designed
to prevent brute-force attacks on users [
Access token generation. Upon successful
authentication, a pair of tokens is sent to the
user: an access token and a recovery token.
Using the access token, the user can make
requests to resources without
reauthentication as the token acts as a guarantor.
Access tokens are mostly valid for a short time
(for example, 15 minutes) so that when stolen,
an attacker cannot pretend to be an
authenticated user for a long time [
Access token refreshment using the refresh token. Refresh tokens are generated for authenticated users to be able to obtain a new access token after the previous one has expired without having to reenter a password every fifteen minutes to retrieve it [26].
Role-Based Access Control (RBAC). The service provides an opportunity to perform authorization using roles. That is, the user has a set of roles that were given to him, and the client can create his requirements for certain actions by comparing the requested roles for authorization of the action with the roles that the user has. Upon successful verification, the user will be authorized to perform a specific action [27].
Attribute Based Access Control (ABAC). Also, the service provides an opportunity to perform authorization using attributes [28]. The user has a set of attributes that were given to him and the client can create his requirements for certain actions by comparing the requested attributes to authorize the action with the attributes that the user has. Upon successful verification, the user will be authorized to perform a specific action [29].
Mixed authorization. This type of authorization expands the set of possible options for granting rights to users and allows better implementation of the least privileges rule [30]. That is, do not give the user extra rights that can lead to unpredictable consequences of the program’s operation. At the same time, the check is carried out separately for roles and separately for attributes. This division allows for a better delimitation of authorization because, for example, not everyone who can delete a user is an administrator, but every administrator should be able to delete a user. Also, a database was designed (Fig. 6) in which all the necessary data for a service to be able to function is stored [31], namely: 1. Users—table for storing users’ information (name, email, phone number, hashed password, etc.). 2. Roles—table for storing role information that can be created in a system to be able to implement an RBAC authorization. 3. Attributes—table for storing attribute information that can be created in a system to be able to implement an ABAC authorization. 4. Clients—table for storing client information. 5. UsersRoles—table for implementing many-to-many relationships between User and Role tables. 6. UsersAttributes—table for implementing many-to-many relationships between User and Attribute tables. 7. AttributesRoles—table for implementing many-to-many relationships between Attribute and Role tables [32].
During the development of the application, a code-first approach was used to create the database in which the SQL code is generated automatically based on the server language code. In this case, C# 10 was used in conjunction with the Entity Framework Core data access tool [33].
The entity relationship diagram is presented below (Fig. 7):
Password-based client and user authentication. In the first stage, it is checked whether the user exists at all and, if so, whether his profile is blocked and whether the temporary password is valid if it was enabled. Then their hashes are checked. The password entered by the user is hashed using the same hash function (SHA-256) and using the same “salt” that is stored in the database and is unique per each user. If more than 5 unsuccessful login attempts are made the user profile will be blocked.
Confirmation code generation. The confirmation code that will be sent via e-mail or SMS is selected as follows: a pseudo-random number between 100000 and 999999 is generated. That is any six-digit number. These are pseudo-random numbers that are an important element in solving cybersecurity problems [34].
Password reset. When choosing the password recovery option, the service generates a new secure pseudo-random 20character password. A pseudo-random sequence of bytes is also generated which acts as a “salt” for hashing the password.
JWT-token generation. JWT tokens are generated using the asymmetric RSA encryption algorithm, the key size is 256 bits. Generation sequence: • The private key is extracted from the settings and an RSA object is created. • A new signature is created for the JWT token. • The token itself is created and signed with the corresponding key. usually after its expiration date, by filling out the appropriate form.
Processing of JWT token in HTTP request. Before any request that requires the user to be authenticated, a check is made to see if the token is present in the request header and if it is, the data from the token is retrieved and stored in a temporary storage for the request duration.
When RBAC is performed the required roles for authorization and the user roles are compared.
When ABAC is performed the required attributes for authorization and the user attributes are compared.
Authorization attribute. The authorization attribute checks whether the request sent to the service is authorized, i.e. it checks whether the JWT token was successfully verified and the client/user data were placed in the temporary storage [35].
The following tools were used to send messages to the phone and email: • For sending SMS the service was integrated with the Twilio [36]. • for sending emails the service was integrated with the SendGrid [37].
In both tools, a service user profile was created and configured and service integration was configured using the NuGet package.
The selection of the type of the correct authentication and authorization method depends on the task we’re performing. It’s appropriate when we’re working on a new system deployment to test some alternative
JWT-token validation. To validate the token mechanisms and see which one leads to better service validates the following: the lifetime of protection from malicious attacks. the token, the signature key, and the issuer. OAuth and OIDC are both important
Refresh token generation. When a recovery protocols for developers to understand, with token is created, a pseudo-random sequence of OAuth providing authorization and OIDC bits is generated, which is stored in the providing authentication and identity database and sent to the user in response to management. By understanding the successful authentication. differences between these two protocols,
Obtaining a new access token using a developers can make informed decisions on recovery token. The recovery token can be how to go about building authentication and regenerated by sending a corresponding integrating with third-party services. request. Then, with its help, you can update the The paper considers the issue of creating a access token without filling out the secure service for the authentication and authentication form again. You just need to authorization of users, which can be send a request to update the access token, implemented as an independent or built-in service. In the first case, the service can be placed on a separate secure server with limited access, to which requests are sent via the Internet. The second option of using this service is in an internal controlled network, requests to which are sent exclusively in the internal intranet network.
The service provides various options for the authentication mechanism which allows you to implement various scenarios depending on security requirements. The service also provides protection against brute-force attacks, the ability to reset the password, and restore the blocked user’s profile.
Both the RBAC and ABAC mechanisms were used in the design of the service for the authorization process. The ability to use mixed authorization allows you to expand the capabilities of RBAC authorization, which is usually suitable for implementing simple business rules, with the ABAC approach, which supports data filtering and rules with dynamic parameters.