Asp net windows аутентификация

Probably almost all of you have developed or are developing ASP.NET applications that allow users to manage their own data and resources in a multi-user environment. These will require that each user has his own user name and password, which he uses to log into the web application, and access his information.

To accomplish this, you may be using, or have used, ASP.NET Forms authentication. The user enters his username and password in the login page and, after they are authenticated against some database tables, he is ready to operate.

In this article I would like to propose a different schema that relies on users’ Windows accounts rather than Forms authentication, and show the benefits that this approach can offer.

We will consider only those ASP.NET applications that are owned by an organization in which all users have their own Windows account, maybe stored in the company’s Active Directory.

Authentication and Authorization

When we create a web application, we want to expose the application’s users to information. This might be text, data, documents, multimedia content, and so on. Sometimes, we also need to manage access to this information, restricting certain users’ access to some of them. This is where authentication and authorization come in.

Before presenting this Windows account authentication and authorization proposal, I would like to define what authentication and authorization mean, the difference between the two and how the .NET Framework manages them. If you are already confident with these concepts you can skip to the next section.

Authentication

Generally speaking, Authentication is the ability to identify a particular entity. The need for authentication occurs when we have some resources that we want to make available to different entities. We store these resources in a centralized place and instruct the system that manages them to prevent entities that we don’t recognize from having access. Anonymous authentication refers to a situation in which we grant access to resources to all users, even if we don’t know them.

In web applications, we expose resources to users. We authenticate each user by requesting his credentials, normally a username and password, that we have assigned to him, or that he got during what we call the registration process.

The .NET Framework uses the following authentication terminology:

1. Principal: this represents the security context under which code is running. Every executing thread has an associated principal.
2. Identity: this represents the identity of the authenticated user. Every Principal has an associated identity.

It also defines the following classes, contained in the System.Security assembly:

1. GenericPrincipal, WindowsPrincipal
2. GenericIdentity, WindowsIdentity

As their names suggest, WindowsPrincipal and WindowsIdentity are related to Principals and Identities associated with a Windows account, while GenericPrincipal and GenericIdentity are related to generic authentication mechanisms. GenericPrincipal and WindowsPrincipal implement the IPrincipal interface, while GenericIdentity and WindowsIdentity implement the IIdentity interface.

Authorization

Authorization is the ability to grant or deny access to resources, according to the rights defined for the different kinds of entities requesting them.

When dealing with Windows Operating System, and its underlying NTFS file system, authorizations are managed by assigning to each object (files, registry keys, cryptographic keys and so on) a list of the permissions granted to each user recognized by the system.

This list is commonly called the “Access Control List” or ACL (the correct name is actually “Discretionary Access Control List” or DACL, to distinguish it from the “System Access Control List” or SACL). The ACL is a collection of “Access Control Entries” or ACEs. Each ACE contains the identifier for a specific user (“Security Identifier” or SID) and the permissions granted to it.

As you probably already know, to view the ACL for a specific file, you right-click the file name, select Properties and click on the Security tab. You will see something like this:

Figure 1: ACL editor for a demo file.

The “Group or user names” section lists all the users and groups, by name, which have at least one ACE in the ACL, while the “Permissions” section lists all the permissions associated with a specific group or user (or, rather, with its SID). You can modify the ACL by pressing the Edit button.

To view the ACL of a specific file using the .NET Framework, you can use the FileSecurity class that you can find under the System.Security.AccessControl namespace. The following example shows how to browse the ACL of a file named “C:\resource.txt”:

By running this code in a console application, you get the following output:

Figure 2: Output of a console application that lists the ACEs of a demo file.

Authentication in IIS 7 and 7.5

With definitions out the way, we’re ready to see how to setup a Windows account authentication and authorization schema in an ASP.NET application. First, we’ll look at how authentication with Windows accounts works.

It’s important to note that this type of authentication doesn’t involve the ASP.NET engine. It works at the Internet Information Server (IIS) level instead, so all that’s required is the correct IIS configuration. The authentication types available in IIS can be viewed by using the IIS Manager:

Картинка с сайта: www.red-gate.com

Figure 3: List of all authentication methods implemented in IIS 7.0 and 7.5.

Anonymous Authentication: this is the most commonly used type of authentication. With it, all users can access the web site.

ASP.NET Impersonation: this is not really an authentication method, but relates to authorizations granted to a web site’s users. We will see later how impersonation works.

Basic Authentication: this is a Windows account authentication, in the sense that the user needs to have a username and password, recognized by the operating system, to use the application. When the user calls a web page, a dialog box asking for his credentials appears. If the user provides valid credentials for a valid Windows account, the authentication succeeds. This type of authentication is not considered secure because authentication data is transmitted to the server as plain text.

Digest Authentication: this is similar to Basic Authentication, but more secure. Authentication data is sent to the server as a hash, rather than plain text. Basic Authentication and Digest Authentication are both standardized authentication methods. They are defined in RFC 2617.

Forms Authentication: this is ASP.NET’s own authentication, based on the login page and the storage of users’ credentials in a database, or similar location.

Windows Authentication: this type of authentication uses the NTLM or Kerberos Windows authentication protocols, the same protocols used to log into Windows machines. As for Basic Authentication and Digest Authentication, the credentials provided by the user must match a valid Windows account.

There are two other authentication methods that I have not mentioned here: Active Directory Client Certificate Mapping Authentication and IIS Client Certificate Mapping Authentication. Both use the X.509 digital certificate installed on the client; how they work is outside the scope of this article.

For the purpose of this article, we can use Basic Authentication, Digest Authentication or Windows Authentication, each of which relies on Windows accounts. When they’re used, the current executing thread is associated with a Principal object that is able to give us information about the authenticated user. I wrote a simple application that shows you how to do that. Its source code is available at the top of this article as a zip file.

The application defines a method, called WritePrincipalAndIdentity(), which give us the following information:

1. The name of the authenticated user.
2. The user’s role, by checking its role membership.
3. The type of authentication performed.

The method’s body is given by:

Where the WriteToPage() method is a helper method that encapsulates the logic needed to write text inside the page.

Rather than using Thread.CurrentPrincipal, we could use the User property of the Page object to achieve the same result. I prefer to use the Thread.CurrentPrincipal, to point out that the principal is always associated with the executing thread. The importance of this will be clearer in the Role-Based Security Paragraph.

When we run this application, using, for example, digest authentication (remembering to disable the anonymous authentication) the logon window ask us for our credentials.

Картинка с сайта: www.red-gate.com

Figure 4: Logon dialog box. To access the web site we need a valid account defined in a domain named CASSANDRA.

If we provide a valid account defined in the CASSANDRA domain we will able to log on to the application. Once we’ve provided it, we obtain something like this:

Figure 5: Demo web application’s output.

Figure 5 shows that the identity of the user who performed the request has been authenticated. It also shows his user name is “CASSANDRA\matteo”, the domain account used to perform the request, that the authentication method used was “Digest Authentication”, and that the user is not an administrator.

Suppose that we need to write a web application that associates the user with his own data, for example a list of contacts or some appointments. It easy to see that, at this stage, we have all the information needed to manage all the data (contacts or appointments) related to a single user. If we save all of them in a database using the username (or better a hash of it) provided by the authentication stage as the table key, we are able to fill all the application’s web pages with only the user’s specific content, as we do with Forms authentication. This is possible without having to write any lines of code.

Another important advantage comes from the fact that, by using the Principal object, we are able to check if an authenticated user belongs to a specific security group. With this information, we can develop applications that are “role-enabled”, in the sense that we can allow a specific user to use only the features available for his role. Suppose, for example, that the web application has an admin section and we want to allow only administrators to see it: we can check the role of the authenticated user and hide the links to the admin page if the user is not an administrator. If we use Active Directory as container for users’ credentials, we can take advantage of its ability to generate group structures flexible enough to generate role-based permissions for even very heterogeneous kinds of users.

However, from a security point of view, authentication alone is not enough. If, for example, we hide the link to the admin page for non-administrator users, they can nonetheless reach the admin page using its URL, breaking the security of the site. For this reason, authorization plays a very important role in designing our application. We will now see how to prevent this security issue occurring.

Authorization in ASP.NET Applications

Suppose that we have a file, “resource.txt”, inside the web application root that we want to make available only to administrators. We can prevent users who aren’t administrators from accessing the file by setting up its ACL properly. For simplicity, let’s say we want to prevent “CASSANDRA\matteo” accessing it. Figure 6 shows how to do that:

Figure 6: ACL for the CASSANDRA\matteo user with denied permissions.

We have denied the Read and Read & execute attributes to the CASSANDRA\matteo account, but we want to see what happens when our demo application tries to open the file. To do so, we add a new method to it:

The CanLoadResource() method tries to open resource.txt, in order to read its content. If the load succeeds, the “Access to file allowed.” message is written on the page. If an UnauthorizedAccessException exception is thrown, the message “Access to file denied.” is written on the page, as an error. The WriteException() method is a helper method used to write an exception message on the page.

Now we launch our application with authorizations set as in Figure 6 and use “CASSANDRA\matteo” to log into the application. Doing that, we obtain something that should sound strange:

Картинка с сайта: www.red-gate.com

Figure 7: Logon with user CASSANDRA\matteo with permissions as in Figure 6.

As you can see in the Figure 7, resource.txt can be loaded by the application even if the credentials provided for the login refer to an account that has no permissions to access it.

This happens because, in this case, the Application Pool associated with the web application works in Integrated mode, which relates authentication and authorization to different users. Specifically, authentication involves the user identified by the credentials provided, while authorization involves the user account used by the Application Pool associated with the application. In our example, the Application Pool uses the NETWORK SERVICE account, which has permission to access the file.

We’ll try to deny these permissions by modifying the ACL of the resources.txt file:

Figure 8: ACL for the NETWORK SERVICE account with denied permissions.

If we launch our application, we now obtain:

Картинка с сайта: www.red-gate.com

Figure 9: Logon with user CASSANDRA\matteo, still with the permissions in Figure 8.

As you can see, the file is no longer available, demonstrating that the authorization process involves the NETWORK SERVICE account.

To use authorization at the authenticated user level, we need to use Impersonation. With impersonation, we are able to allow the Application Pool to run with the permissions associated with the authenticated user. Impersonation only works when the Application Pool runs in Classic Mode (in Integrated mode the web application generates the “500 – Internal Server Error” error). To enable impersonation, we need to enable the ASP.NET Impersonation feature, as noted in Figure 3 and the discussion that followed it.

If we switch our Application Pool to Classic Mode (enabling the ASP.NET 4.0 ISAPI filters, too) and enable ASP.NET impersonation, the demo application output becomes:

Картинка с сайта: www.red-gate.com

Figure 10: Logon with user CASSANDRA\matteo, with permissions as in Figure 8 and Application Pool in Classic Mode.

We are now able to load resource.txt even if the NETWORK SERVICE account has no permissions to access it. This shows that the permissions used were those associated with the authenticated user, not with the Application Pool’s identity.

To take advantage of Integrated mode without having to abandon impersonation, we can use a different approach: running our application in Integrated mode and enabling impersonation at the code level when we need it. To do so, we use the WindowsImpersonationContext class, defined under the System.Security.Principal namespace. We modify the CanLoadResource() method as follows:

With the modification added, we can force the application to impersonate the authenticated user before opening the file. To achieve this, we have used the Impersonate() method of the WindowsIdentity class (the class to which the Identity property belongs). With it, we have created a WindowsImpersonationContext object. This object has a method, Undo(), that is able to revert the impersonation after the resource has been used.

If we try to run our application with permissions as in Figure 8, we see that we are able to access resource.txt even if the Application Pool is working in Integrated Mode.

Now we can resolve the security issue presented earlier. If we want to use Windows accounts to develop a “role-based” application, we can use authentication to identify the user requesting resources and we can use authorization, based on the user’s identity, to prevent access to resources not available for the user’s role. If, for example, the resource we want to protect is a web page (like the admin page), we need to set its ACL with the right ACEs, and use impersonation to force the Application Pool to use the authenticated user’s permissions. However, as we have seen, when the Application Pool uses Integrated mode, impersonation is available only at code level. So, although it’s easy in this situation to prevent access to resources (like the resource.txt file) needed by a web page, it’s not so easy to prevent access to a web page itself. For this, we need to use another IIS feature available in IIS Manager, .NET Authorization Rules:

Картинка с сайта: www.red-gate.com

Figure 11: .NET Authorization Rules feature of IIS7 and IIS7.5.

.NET Authorization Rules is an authorization feature that works at ASP.NET level, not at IIS or file system level (as for ACLs). So it permits us to ignore how IIS works and use Impersonation both in Integrated Mode than in Classic Mode.

I leave you to test how it works.

Role-Based Security

A further advantage of using Windows account authentication is the ability to use a .NET Framework security feature called Role-Based Security.

Role-Based Security permits us to protect our resources from unauthorized authenticated users. It relies on checking if an authenticated user belongs to a specific role that has authorization to access a specific resource. We have already seen how to do that: use the IsInRole() method of the thread’s Principal object.

The .NET Framework security team decided to align this type of security check to Code Access Security (which I wrote about in previous articles) by defining a programming model similar to it. Specifically, a class named PrincipalPermission, found under the System.Security.Permissions namespace, has been defined. It permits us to check the role membership of an authenticated user both declaratively (using attributes) and imperatively (using objects), in the same manner as CAS checks.

Suppose that we want resource.txt to be readable only by administrators. We can perform a declarative Role-Based security check in this way:

where “myname” is the username that we want to check.

If declarative Role-Based security is not what we need (because, in this case, we need to know the identity of the user first), we can use an imperative Role-Based security check:

In both cases, if the user does not belong to the Administrators group, a security exception is thrown.

The PrincipalPermission class doesn’t add anything to our ability to check the permission of an authenticated user. In my opinion, the IsInRole() method gives us all the instruments we need, and is simpler to use. Despite this, I’ve included PrincipalPermission in this discussion for completeness. Maybe this is the same reason that the .NET development team added this type of class to the .NET Framework base classes.

I end this section by mentioning that Role-Based Security can even be implemented in desktop applications. In this case, the authenticated user is a user that logs into the machine.

When a desktop application starts, by default, the identity of the authenticated user is not “attached” to the executing thread. The Principal property of the current thread and the Identity property of the Principal property are set to GenericPrincipal and GenericIdentity respectively, and the Name property of the Identity property is empty.

If we launch the following code in a Console application:

We get:

Картинка с сайта: www.red-gate.com

Figure 12: Default Identity in a Console Application.

So we see that the application is not able to recognize the user who has logged-in.

This is, however, a feature we can turn on. We need to modify the previous code as follows:

Launching the application, we now get:

Картинка с сайта: www.red-gate.com

Figure 13: Identity in a Console Application.

As you can see from Figure 13, Identity has been initialized with a WindowsIdentity object and the reference to the logged user has been added. We are now able to use Role-Based Security even in desktop applications.

Conclusion

In this article we have seen how Windows accounts can be used to implement authentication and authorization in ASP.NET applications. Even if this type of approach is rarely used, Forms Authentication being the commonly adopted solution, it can have a lot of advantages:

1. Less code to develop and maintain. Authorization and authentication with Windows accounts does not require the developer to write specific code for the management of user credentials, authorizations, password recovery and so on.
2. Centralization of user credentials, access rights, password policies, role-based policies and identity management in general. All the security information related to a specific user is stored in a centralized place, Active Directory. When a new employee arrives at an organization, permissions have to be added only in the Directory structure, not in each web server used by the company, making the authorization process simpler to manage.
3. More security. In a decentralized security environment, sometimes users have to remember more than one username and password. Sometimes they are forced to write them down to remember them. Security experts think this is one of the most dangerous security issues. Moreover, if an employee with, say, ten accounts for ten different applications, stored in ten different places, leaves an organization, it’s easy to forget to remove all their credentials, allowing them to access, or even steal confidential data.

Title: ASP.NET Core Web API Windows Authentication

In this article, we will learn how to secure an ASP.NET Core Web API with Windows authentication. We will cover the following topics:

• What is Windows authentication?
• How to configure Windows authentication in ASP.NET Core
• How to protect endpoints with Windows authentication
• How to test Windows authentication

By the end of this article, you will be able to secure your ASP.NET Core Web API with Windows authentication and protect your endpoints from unauthorized access.

****

In this tutorial, you will learn how to enable Windows authentication in an ASP.NET Core web API. Windows authentication is a type of authentication that uses the Windows NTLM or Kerberos protocols to verify a user’s identity. It is a built-in feature of ASP.NET Core and does not require any additional configuration.

By the end of this tutorial, you will be able to:

• Enable Windows authentication in an ASP.NET Core web API
• Protect your API endpoints with Windows authentication
• Test your API with Windows authentication

**What is Windows Authentication?**

Windows authentication is a type of authentication that uses the Windows NTLM or Kerberos protocols to verify a user’s identity. It is a built-in feature of Windows operating systems and is used by many applications and services.

When a user attempts to access a Windows-authenticated resource, their browser will send a NTLM or Kerberos token to the server. The server will then use this token to verify the user’s identity. If the user is authenticated, they will be granted access to the resource.

Windows authentication is a secure authentication protocol that is widely used. However, it is not as secure as other authentication protocols, such as OAuth 2.0 or OpenID Connect. This is because Windows authentication does not require the user to provide a password.

**How to enable Windows Authentication in ASP.NET Core**

To enable Windows authentication in ASP.NET Core, you can use the following steps:

1. In your Startup.cs file, add the following using statements:

c
using Microsoft.AspNetCore.Authentication.WindowsAuthentication;
using Microsoft.AspNetCore.Authorization;

2. In your ConfigureServices method, add the following code:

c
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = WindowsAuthenticationDefaults.AuthenticationScheme;
});

services.AddAuthorization(options =>
{
options.AddPolicy(“RequireWindowsAuthentication”, policy =>
{
policy.RequireClaim(“WindowsAccountName”);
});
});

3. In your Configure method, add the following code:

c
app.UseAuthentication();
app.UseAuthorization();

4. Restart your application.

Now, when a user attempts to access your API, they will be prompted to authenticate with Windows. If they are authenticated, they will be granted access to the API.

Protecting your API endpoints with Windows authentication

You can protect your API endpoints with Windows authentication by using the [AuthorizeAttribute](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/authorizeattribute?view=aspnetcore-6.0). For example, the following code will protect the `/api/products` endpoint with Windows authentication:

c
[Authorize(“RequireWindowsAuthentication”)]
public async Task GetProducts()
{
return Ok(new List());
}

When a user attempts to access the `/api/products` endpoint, they will be prompted to authenticate with Windows. If they are authenticated, they will be able to access the endpoint.

Testing your API with Windows authentication

You can test your API with Windows authentication by using the following steps:

1. Open a command prompt and run the following command:

cmd
net user testuser testpassword /add

This will create a new user account with the username `testuser` and the password `testpassword`.

2. Log in to your computer as the `testuser` account.

3. Open a browser and navigate to the URL of your API.

4. You should be prompted to authenticate with Windows. Enter the username `testuser` and the password `testpassword`.

5. If you are authenticated successfully, you will be able to access your API.

In this tutorial, you learned how to enable Windows authentication in an ASP.NET Core web API. You also learned how to protect your API endpoints with Windows authentication and how to test your API with Windows authentication.

By following these steps, you can secure your ASP.NET Core web API with Windows authentication.

ASP.NET Core Web API is a powerful framework for building RESTful APIs. It is designed to be lightweight and easy to use, and it can be used to create APIs for a variety of purposes, including internal applications, public-facing websites, and mobile applications.

Windows authentication is a security mechanism that is built into the Windows operating system. It allows you to restrict access to resources based on the user’s Windows account. This can be a very effective way to protect your API from unauthorized access.

In this tutorial, we will show you how to enable Windows authentication for an ASP.NET Core Web API. We will cover the following topics:

• Configuring Windows authentication in your application
• Authenticating users with Windows authentication
• Authorizing users to access resources

Configuring Windows Authentication

The first step is to configure Windows authentication in your application. To do this, you need to add the following middleware to the `Configure` method in your `Startup` class:

c
app.UseAuthentication();

This middleware will automatically authenticate users who are logged into Windows. If a user is not logged into Windows, they will be redirected to the login page.

Authenticating Users

Once you have configured Windows authentication, you need to authenticate users when they attempt to access protected resources. To do this, you can use the `HttpContext.User` property. This property provides access to the current user’s Windows account information.

For example, the following code snippet checks to see if the current user is an administrator:

c
if (HttpContext.User.IsInRole(“Administrator”)) {
// The current user is an administrator.
} else {
// The current user is not an administrator.
}

Authorizing Users

Once you have authenticated a user, you need to authorize them to access the resources that they requested. To do this, you can use the `Authorize` attribute. This attribute can be applied to controllers, actions, and methods.

For example, the following code snippet authorizes users to access the `GetProducts` action on the `ProductsController` controller:

c
[Authorize]
public async Task GetProducts() {
// Get the list of products.
var products = await _productService.GetProductsAsync();

// Return the list of products.
return Ok(products);
}

**

In this tutorial, we showed you how to enable Windows authentication for an ASP.NET Core Web API. We covered the following topics:

• Configuring Windows authentication in your application
• Authenticating users with Windows authentication
• Authorizing users to access resources

We hope that this tutorial has been helpful. For more information on ASP.NET Core Web API, please refer to the following resources:

• [ASP.NET Core Web API Documentation](https://docs.microsoft.com/aspnet/core/web-api/)
• [ASP.NET Core Web API Tutorials](https://docs.microsoft.com/aspnet/core/tutorials/web-api/)
• [ASP.NET Core Web API Samples](https://github.com/aspnet/samples/tree/master/aspnetcore/webapi)

  Q: What is Windows authentication?

A: Windows authentication is a security mechanism that allows users to access resources on a Windows server by using their Windows credentials. When a user attempts to access a resource that is protected by Windows authentication, the server will authenticate the user by checking their username and password against the Active Directory database. If the user is authenticated, they will be granted access to the resource.

Q: How do I enable Windows authentication in ASP.NET Core Web API?

A: To enable Windows authentication in ASP.NET Core Web API, you can use the following steps:

1. In your Startup class, add the following middleware to the `ConfigureServices` method:

c
services.AddAuthentication(options =>
{
options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.DefaultChallengeScheme = “Bearer”;
});

2. In your Startup class, add the following middleware to the `Configure` method:

c
app.UseAuthentication();

3. In your controller, add the following attribute to the action method that you want to protect:

c
[Authorize]
public async Task Get()
{
// Get the user from the context
var user = HttpContext.User;

// Return a response
return Ok(user);
}

Q: What are the benefits of using Windows authentication?

A: There are several benefits to using Windows authentication, including:

• Simplicity: Windows authentication is a simple and straightforward security mechanism to implement.
• Robustness: Windows authentication is a robust security mechanism that is well-tested and has been used for many years.
• Centralized management: Windows authentication can be centrally managed through Active Directory.

Q: What are the drawbacks of using Windows authentication?

A: There are a few drawbacks to using Windows authentication, including:

• Performance: Windows authentication can be more computationally expensive than other security mechanisms, such as token-based authentication.
• Limited cross-platform support: Windows authentication is only supported on Windows servers.
• Single sign-on: Windows authentication does not support single sign-on across multiple applications.

Q: What are some alternatives to Windows authentication?

There are a number of alternatives to Windows authentication, including:

• Token-based authentication: Token-based authentication is a security mechanism that uses tokens to authenticate users. Tokens are typically issued by a central authority and are used to access resources on different servers.
• OAuth 2.0: OAuth 2.0 is a popular authorization framework that can be used to implement token-based authentication.
• OpenID Connect: OpenID Connect is an identity layer built on top of OAuth 2.0. It provides additional features, such as user profile information and single sign-on.

Q: Which authentication mechanism should I use?

The best authentication mechanism for your application will depend on your specific requirements. If you need a simple and robust security mechanism that is well-supported, then Windows authentication is a good option. If you need a more performant or cross-platform solution, then you may want to consider an alternative authentication mechanism.

In this article, we have discussed how to implement Windows authentication in ASP.NET Core Web API. We first looked at the different authentication schemes available in ASP.NET Core and how to configure them. Then, we discussed how to implement Windows authentication using the `IdentityServer4` library. We also covered how to protect your API endpoints with Windows authentication and how to allow unauthenticated users to access some endpoints.

We hope that this article has been helpful and that you are now able to implement Windows authentication in your ASP.NET Core Web API applications.

Here are some key takeaways from this article:

• Windows authentication is a secure authentication scheme that can be used to protect your ASP.NET Core Web API applications.
• To implement Windows authentication, you can use the `IdentityServer4` library.
• You can protect your API endpoints with Windows authentication by using the `Authorize` attribute.
• You can allow unauthenticated users to access some endpoints by using the `AllowAnonymous` attribute.