I am adding authentication to an existing .net MVC project that is mostly APIs with a SPA interface. I don't want to hook up the whole ASP.net identity library for something as small as this project. I just want simple accounts with name, email, and password, and an API method to register(), login(), and logout(). What's the simplest way of implementing bearer token authentication without ASP.net identity?
I took #BradChristie's advice and created a super simple OWIN authentication layer.
I've posted all of the essential files, install instructions, and test instructions to a separate GitHub Gist.
Related
I am going to create an web app using Dot Net Core. In future, i will also create mobile application for the same application. Now, i am in thinking the architecture of the project. I want to use WEB API core using Asp.net Identity Core. Also, i will consume WEB API in MVC Core application. But the question i have in mind that how i can handle ASP.net identity with MVC and WEB API? Do i need to include in MVC as well or only in WEB API?
I tried to think hard but still confuse. Need suggestions.
You can use token based authentication .
In a resource owner flow scenario , your client app( mvc application/native application) will consume your web api by providing user's credential , web api will validate the credential(using ASP.NET Core Identity) in database , If the username and password are correct then a JWT authentication token and the user details are returned. Your client app could validate the token and sign in user :
ASP.NET Core 2.2 - JWT Authentication Tutorial with Example API
Tutorial built with
Token Authentication in ASP.NET Core 2.0 - A Complete Guide
In addition, IdentityServer4 is a good choice when you want to roll your own full-fledged OpenID Connect authorization server that can handle complex use cases like federation and single sign-on.
So your question is maybe a bit open-ended for Stackoverflow and you don't really show what you have tried so far.
I will try to answer though. First you just need to start out with a template for your project. Start an MVC project in which you can easily have API endpoints as well. I would suggest splitting those in two projects for clarity - but if it is just a small personal project then you probably are fine having them in the same project. Microsoft have a pretty good resource on MVC:
Microsoft MVC walkthrough
For the Identity part. You would need some kind of authority for it to work. I suggest you take a look at IdentityServer4. Which offers an excellent walk-through of how to set it up and how to integrate it with Asp.NET Core Identity:
IdentityServer4
I'm wondering if it is possible to use Thinktecture IdentityServer simply as an STS alongside an existing web app? That is, I want to use ASP.NET Identity for authentication in my web app because I want to use all of the built-in functionality like 2-factor, etc. However, I want to use IdentityServer as an STS to serve up tokens to access my web services (WCF and Web API).
I thought perhaps I need to authenticate normally through ASP.NET Identity, then again through IdentityServer to get the token. However, this seems heavy and wasteful.
Is there perhaps some way to authenticate against the IdentityServer directly from ASP.NET Identity? I saw the sample where we can integrate the two together (IdentityServer using ASP.NET Identity), but it seemed like I might lose the ability to use all of the built-in stuff like two-factor workflows.
I'm hoping I'm way off base here, and apologies if I have some fundamental misunderstandings about how IdentityServer works. Perhaps there is a way to get all of the added functionality that ASP.NET Identity provides from within IdentityServer?
Identity Server will handle all authentication, no need for double sign-ins if you are using it correctly.
You'll have to implement two factor authentication yourself though as it is not currently supported by Identity Server. However extending Identity Server's existing support for ASP.NET Identity to allow for two factor authentication is definately possible.
I think your first port of call should be to have a bit of a deep dive into the Identity Server documentation and the OpenID Connect protocol. After that check out UserService documentation and then derive from the existing ASP.NET Identity UserService to add support for two factor authentication.
We're building a Windows-authenticated ASP.NET MVC app. This will then call into an ASP.NET WebAPI layer sat on a different server.
We don't have Kerberos enabled so assume authentication with this will be via some form of Basic auth. We're also looking to use ASP.NET Membership/Identity for role management. All communication with the Membership database will be via the WebAPI.
Can anyone give guidance on how best to handle issuing authentication tokens for communication between the MVC and WebAPI apps, and how Authorize attributes may be used across both layers?
I've blogged detailed series of posts about Token based authentication in Web API using ASP.NET Identity, it should answer part of your questions, check it here
I have an app that uses my own membership system. It uses ASP.NET MVC 3 which I'm updating to ASP.NET MVC 5. It's not possible to change the membership to use a new one like ASP.NET Identity. But, for the authentication side, do you think it is a good idea to replace my auth-ticket system with OWIN.Security? Are there any traps that I should know about?
The Katana security middleware is independent from ASP.NET Identity. You can use them both or just one.
There are some cases where it makes very good sense to use just the Owin/Katana middleware, but not involve aspnet identity.
I just rolled up a prototype webforms application using OpenID Connect against an Azure Domain. My domain is Federated with an on-prem ADFS. By the time I got OpenID Connect and the GraphAPI working, I realized that I didn't really need much from aspnet identity.
I use the GraphAPI to grab extra info about the user and their group memberships, and I am adding that info as claims on the user principal... my site's code can operate against just the information in the claims.
Of course, if you want to do any custom profile or role stuff in your application, it probably makes sense to link it to aspnet identity too.. create an aspnet identity user when a new user authenticates, map that user's AD groups to roles, etc. Then you can manage application specific data for the user directly in the application via aspnet identity, while relying on Azure AD for the core authentication, basic profile, and group/role assignments.
I'm new to the ASP.NET world. Since I want to use the ORM it seems I would want an Entity to represent the User or Member or whatever, not some data tucked away by the forms authentication api. In fact I don't see how I can live without one.
How do people deal with this? Roll your own authentication? Or is there a best practice for incorporating forms authentication with the Entity Framework?
In short, since I need a User and Role Entity for queries anyway, should I skip the forms auth or find a way to use it?
Thanks
EF and Forms Auth are really two different areas. You can use Forms Auth without ASP.NET Membership very easily and roll your own provider with very little effort.
This tutorial will show you how:
http://msdn.microsoft.com/en-us/library/ms172766(VS.80).aspx
With ASP.NET MVC you should really use standard Auth since you can manage access to controllers using attributes for Roles very easily.
FormsAuthentication on its own does not care about the identity store and can validate only credentials stored in the web.config <credentials> section, through the Authenticate method. Standard implementations of the login page use the static Membership class to manage the identities and credentials in the MembershipProvider specified in the config file (usually SqlProfileProvider).
However, you don't have to use the membership provider functionality of ASP.NET to maintain your identities and you can still use FormsAuthentication just fine. The forms authentication control flow shows that forms authentication deals primarily with creating and maintaining the auth ticket for the user in a cookie. It does not deal with the user identity or profile itself, as it does not care about those.
Thus, you can safely use EF to maintain your user profiles, including credentials and do authentication of the provided credentials in your login page, while still using FormsAuthnetication.