I know there is a lot of questions out there already and I've been reading blogs and looking at samples for well over a week and I'm still a little hazy on how some of this is going to work in the real world. The samples are very helpful, some are very complex some are simple, none have really clarified some of my questions.
The system comprises:
Web App (own IIS site, with SSL, consumes Public API)
Public API (own IIS site, with SSL)
Desktop Widget
Mobile (iOS, Android)
3rd Party apps
How best to handle user registration and account creation? Whilst offering OpenID there also needs to be a 'local' login to the web application. Having a method on the API that accepts base data types (strings/dates etc...) values and then creates an account is asking for trouble and a red flag to the spammers. Would it be best to handle this exclusively through the web site employing visual CAPTCHA checks? How does the Facebook mobile app handle this registration scenario?
Lots of samples also seem to use small subsets of the default Forms Authentication database for Membership. They then use Entity Framework and the Membership, WebSecurity or FormsAuthentication, Roles Provider classes in various different ways depending on use case. Are there any alternatives to this approach to consider for the security backend? Our DB guy is considering rolling our own but then we also need to build our own user management app :(
Once a user is registered and logged in to the web app I can't see any way around continuing to authenticate and authorize each call on the WebAPI. I'm assuming at the moment that the API should just implement OAuth and treat the web app as another client app like the mobile app and 3rd party apps.
I think I've read too much without playing with code to settle this in my head. There are so many approaches.
TIA,
Related
I am building a web app using react that calls RESTful API (built using .NET Core 3.1). The web app and soon mobile app access all data through the API. I would like to have an authentication/authorization integrated but would like to know where to start. I am thinking of IdentityServer4 to build a token service but that could be an overkill and especially security not being my speciality. But i also would like something that I can easly integrate/use but also not tied with just only one token provider (eg, MS only) - this will be too restrictive as the target users could potentially prefer to use username/password, or their google/MS/fb....). What do I do? where should I start?
I don't know the complexity of your project. Give some suggestions aobut it.
If the complexity of the project is average, you can use jwtbearer authentication and use the built-in authorization. Because you have used the front and rear separation and And authentication and authorization can be well separated according to the httpstatus.
If you do not use jwt, you can use identity. Because asp.net core has integrated identity well. But jwt is a better suggesion.
If the business you are dealing with is relatively complex, you can consider IdentityServer4. You need to configure authentication and authorization on an another server.
Well here are the moving parts, and there is quite a big learning curve, since OAuth tech covers many architectural aspects. I would aim to focus primarily on UI and API integration in the early days.
Authorization Server (AS)
This will deal with login screens, standards based messages, issuing tokens, auditing and so on. I'd recommend starting with a free or low cost cloud service, so that you can get started quickly and understand how to manage the system.
APIs
These will verify incoming access tokens and build a claims principal. I would start by understanding which claims you need and how you will authorize requests after validating the token.
Web UIs
These use Authorization Code Flow (PKCE), then handle and verify OAuth responses. A commonly used library is oidc-client, which will deal with a lot of the complexity for you.
Mobile UIs
These use the same flow above but with the use of in app browsers that handle credentials. The most commonly used library is AppAuth, which deals with the mobile plumbing.
Extensibility
Once the above parts are integrated you should then be able to do this without any code changes:
Add extra login methods, as discussed in my Federated Logins Blog Post
Switch providers once you better understand your AS requirements
Online Code Samples
My blog has a bunch of UI and API Code Samples you can run on your local PC, starting with the Initial Code Sample, then moving on to more advanced ones such as React SPA with .Net Core API.
IdentityServer4 is a good choice, not that hard to incorporate in your project. You may say it may be complicated but it simply provides an authorization API issuing authentication tokens for users requests(it provides a user and password as identity), and it gives you the option of deploying external authentication(FB,Google...). It is not an overkill as when it comes to security the more it is sophisticated the better.
here is a guide if you'r interested: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-5.0
Perhaps this is a stupid question, but I honestly don't know where to start.
I currently have a .NET Core 2 MVC project using Entity Framework. In this MVC app a user can:
sign up
confirm his email
login
change password and add basic profile information
reset his password using "forgot password"
Now I want to build a VueJS SPA in which the user can log in as well using .net core 2 webapi. All the hooks for this api are already build and are working as expected.
The MVC, API and SPA parts would all live on a separate subdomains:
www.site.com for MVC
app.site.com for SPA
api.site.com for API
My question: Is there a way to let the user:
Login using the MVC website or spa/webapi
Share the login on both systems (when going back to the marketing website, a "Go to app" button appears and the SPA recognizes the authenticated user
The same behavior can be found on the website www.clubhouse.io. This seems to be exactly how I'd like my website to work :)
The de-facto technology for what you're after is OAuth 2.0.
You'll need a component to act as an identity provider, which (depending on your requirements) may federate with social identity providers too.
As with most things security, rolling your own authorisation server is a really, really bad idea. Plus, it's already a (mostly) solved problem.
Realistically you've got a few choices:
Use a third party identity service (Okta, auth0, etc)
Use a standalone, off-the-shelf authorisation server product
Integrate an off-the-shelf authorisation server library
Given you already have a server-side rendered MVC application, #3 is probably the best approach.
Right now it looks like the best tool out there for .NET is IdentityServer.io. I'd head over that way and get cracking for implementation.
A helpful hint along the way: given your SPA application can't keep a secret (its source code is fully available to clients), the only appropriate authorization grant type is "Implicit".
I've been reading a lot lately about WEB API authentication mechanisms and I'm a little bit confused regarding how to implement my Web API authentication mechanism, I'm thinking on using Token based authentication but I'm not sure if it is the right choice.
Basically my Web API will manage all the operations needed and it will store the users of my website as well the API users(in case they have to be separated).
I want to support the following
User can register on my website and apps using their G+ or Facebook account or an already created username from my service, as well they will be to login using their social account.
If the user is not logged in they won't be able to post Items but they will be able to see the Items, think something like Craiglist.
Let's say the user is a developer and they want to post the items through some software they created instead of going through the website and posting one item at a time, how do I allow this?
Now, my questions are: 1) When a user registers on my website, do I have to create a (public key/ secret key) for it subsequent access token , so I can use my API from the website as the user checking if they have access to certain endpoints?
2) Do I have to assign a (public key / secret key) for my website so I can consume the API when the user is not logged in?
3) The same as above for mobile apps
4) How do I allow users to (sign up / sign in) using G+ or Facebook?, if they log in using any social network how am I going to secure my api?
Please, any answer will be really appreciated.
Thanks
For ASP.NET Web API 2, I would recommend you to use the default Owin OAuth2 authentication. It's a standard form of authentication well documented enough. If you do not have enough knowledge about OAuth2, read the RFC.
With Web API 2, ASP.NET moved to a new security model, called ASP.NET Identity. There is this really good video that explains the basics. The point is that starts from scratch, ignoring traditional basic, forms, or windows authentication.
A lot of learning material is on the ASP.NET website.
For local, individual accounts (questions #1, #2, and #3), look through this tutorial - here basically your own server will act as an OAuth authorization server, and the Owin OAuth2 implementation will take care of generating access token and authenticating them. Since you'll be using the OAuth 2 standard, it will be basically the same for mobile as well.
For external accounts (question #4), read through this tutorial. There are official libraries for third-party authentication for the major providers:
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Twitter
Microsoft.Owin.Security.MicrosoftAccount
It would helpful to also learn more and understand the new OWIN specification, that describes how web apps need to created for the .NET framework, and the Katana project (Microsoft's OWIN implementation).
Follow this tutorial for most of your requirements http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/ Logging in via facebook/G+ MVC already has the helpers commented out. You would get the credentials by setting up key's via the third party apps and then store the identity.
I'm struggling with these concepts and having trouble finding good resources on the web.
We are looking for ways to switch out custom implementations tightly integrated into our application for standards based authentication and authorization.
Our scenario is as follows:
A simple web site (may be an app in the nearby future)
A user must log in or otherwise gain access (i.e. there's no "guest" content or other things you can do as a guest)
The site uses its own web services (REST and/or SOAP) on the backend, but it might use 3rd party web services or exposes its own services as 3rd party services for other applications
Authentication may very well be done by an external provider: Users carry a smartcard and we'd like to have one simple identity provider which reads the smartcard information and sends it back to my simple web site (so I know who the user is and what his role is for instance)
Other sites might use other methods of authentication (simple username/password for instance), so we might need a configurable Service Provider??
I'm currently looking at OAuth (2) to implement for authorizing use of our REST Services (is it also useful for SOAP?) to our web site, perhaps with a simple "Client Credentials Grant" type.
But for authentication, I'm still none the wiser. There is OpenID, but is it easy enough to build your own OpenID Identity Provider? There is Shibboleth, but it seems to have a steep learning curve for doing custom stuff. And I've looked at just building something from scratch based on the SAML Authentication Request Protocol with an HTTP Post binding. Are there any other options?
Please keep in mind that we want to be flexible with our authentication. For a certain site, we might want to do the smartcard thing, but for another maybe simple username/password login with LDAP.
If it's helpful still, I personally thought about doing it myself, then discovered a bunch of third parties. I compared (5/18/2015):
Auth0
AuthRocket
UserApp
DailyCred
Conclusion for me was Auth0, because while all the features are very similar, it felt the most legitimate, as in it's not a start-up that might disappear in a few months. Now, the reason that was super important for me was because login is a foundational requirement, so I need to believe as a customer that the Authentication as a Service will be up for as long as I will be.
Here's the full comparison story:
https://medium.com/#bsemaj/authentication-as-a-service-comparison-5-quick-lessons-for-b2b-businesses-e7587275824c
Given I have an existing user store as database and are not allowed to use google, facebook, twitter, etc logins in a business scenario. What would be the best practise to do authentication against a backend server?
As backend I plan to server Json via web api. Since Web api implements oauth2 and Windows store apps do also. Is there an easy way to leverage the oauth2 protocol with for example asp.net membership (or different user store). I know this is a totally different concept but I was looking for a solution to use build in infrastruktur... without to have or install an identity server.
Since the Windows Store App are not a browser, so how do the token back and forth dance work with the back end...
So these are just my thought ... How would be story for authentication for Windows 8 store apps in LOB cases?
Any pointers, links, thoughts would be highly appreciated....
You can use the WebAuthenticationBroker class to present a web-view (browser view) and do all the things required for oauth in client side. One important note: you have to call this broker's authenticate method in the main/UI thread! There's even a Facebook example at the link. For server/backend: I'm not familiar with asp.net based backends, we use Ruby on Rails with oauth gem.