ASP.NET Custom Authentication Service + OWIN or ASP.NET Identity 2.0?

Question

ASP.NET

Good afternoon! I ask for help in the issue of building authorization / authentication in the N-Layer application.
The application uses a three-tier architecture:

• DAL - Data Access Level (Class Library) : (Entities, Repositories, UnitOfWork)
  
• BLL - Business Logic Layer (Class Library) : (DTO, Services)
  
• WEB(UI) - Presentation Layer (ASP.NET MVC 5) : (ViewModels, Controllers)
  

Task: it is necessary to make authentication and authorization.
I honestly spent two days learning ASP.NET Identity 2.0, poked around, tried different options. Metasite
even has an example of using ASP.NET Identity in a layered architecture. But in the end, I came to the conclusion that spreading ASP.NET Identity over different layers and connecting dependencies, some kind of mess is obtained, and the whole application structure looks unsuccessful and not very convenient. So, many obscure dependencies appear, for example, I need to use the GeneratePasswordResetToken method , which is logical to do in my own UsersService service, in which to call the above method. But it pulls UserTokenProvider initialization
, which is implemented using OWIN .
As a result, it turns out that ASP.NET Identity + parts of OWIN (Security) are superimposed on all layers of the application, and it does this very inaccurately.
Therefore, I began to look towards the implementation of my own UsersService service with the methods that I need, and implement this service in the same way as all services are implemented in the application being developed.
Plan:
[DAL layer]
In addition, to complete the task, I only need simple tables Users (UserId, Firstname, Surname, Email, Gender, etc), Roles (RoleId, RoleName) and UserRoles (UserId, RoleId) for communication .
I can create all this as ordinary entities and work with them using the familiar Entities -> DTO -> ViewModel model, etc.
[layer BLL]
As for the UsersService service itself, the basic methods are assumed:
(All methods are very approximate, I'm trying to convey the essence of my confusion)
- IEnumerable GetUsers(/*Filter*/);
- UserDTO CreateUser(UserDTO user);
- UserDTO GetUser(int userId);
- UserDTO GetUser(string email, string password);
- void UpdateUser(UserDTO user);
- void RemoveUser(int userId);
- void ResetPassword(int userId);
- bool CheckResetPassword(int userid, string code);
- bool IsUserInRole(int userId, string roleName);
...
and the like (all of these methods are found in ASP.NET Identity , and in any other authorization library).
[WEB layer]
I liked OWIN itself and if you use it in only one place, it looks great. Therefore, in the WEB layer, I would connect OWIN + all dependencies and use authorization with cookies and Claims. I will need Claims to just write UserFullname and all such data to cookies for display in View.
In the end, you will get your own user provider in the form of UsersService + OWIN on the WEB.
Main questions:
1. Will everything be safe enough if everything is implemented in this way? (As for the password hash generation, I will take the generation from ASP.NET Identity, it is available here ).
2. Are there any important points that I missed, and ASP.NET Identity is in any way better than my solution? (except for the time spent on the implementation of the UsersService service).
I really need advice on these matters!
Thanks in advance for any help!

Answer 1

1) Enough
2) Identity implements the basic functionality of working with users / roles, etc., the ability to connect authorization through third-party services.
If you need the simplest authentication / authorization, then Identity as a whole is not needed, it will be enough to find a user in the DAL with the specified login and password and authorize him.
Pseudocode:

public User Validate(string login, string secret)
{
  return DbContext.Users.FirstOrDefault(x=>x.login == login && secret == secret );
}  
public async void SignIn(User user)
{
  List<Claim> claims = new List<Claim>();	
  claims.Add(new Claim(ClaimTypes.Name, user.Name));
  ClaimsIdentity identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
  ClaimsPrincipal principal = new ClaimsPrincipal(identity);
  await HttpContext.Authentication.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);
}
public async void SignOut()
{
  await HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
}

The rest of the logic of working with users and roles is written quite easily. The only question is whether you need to fence your bike.