I am building a web application with
Asp.net Core 2.0 Web API
AngularJS 4+
SQL Server
User signup/login only through Google/Facebook/LinkedIn. I will save user info like name and email I receive from them into SQL db table. I do not have a plan to offer manual registration on my website with email and password. I do not want to maintain user credentials, forget the password, securing user passwords and all nitty-gritty around that.
As of now, there is no plan to build a mobile app. I am learning .Net Core and stumble upon IdentityServer4 as a recommended way to provide identity in asp.net core applications. I went through all docs, example and tried out few sample application. I think I am clear how configuration and workflow of identityserver.
My questions are
Is it worth employing IdentityServer4 in my architecture since my identity is external provider only? I was thinking about using default Asp.net Identity with.AddCookie(), .AddGoogle() and .AddJwtBearer() to retrieve the cookie from Google/Facebook/LinkedIn, use AddGoogle AddFacebook AddLinkedIn middleware to handle callback, extract claimprincipal and set Jwt token for Angular JS app to use in its XMLHttp request.
What benefits do I get outsourcing this work to IdentityServer4 besides identity in one place best practice?
I appreciate your tiny or big feedback on this.
IdentityServer is great for handling many clients that access many protected resources. You seem to have one client (the so called AngularJS 4+ app) and one resource, the Asp.net Core 2.0 Web API.
A point of clarity is that you have no need for ASP.NET Identity and all those middlewares for Google, LinkedIn, etc. If your client is truly an Angular javascript application, then it does not need a server side component like ASP.NET Core- it is simply a browser application. You can use a javascript library like oidc-client and configure your external authentication providers according to their own needs. You will receive an id_token and/or access_token to store in browser and utlimately pass to your Api Resource.
Speaking of your Api Resource, this application can validate directly with the token issuer, be it Google or Facebook or whoever.
So with this setup: (a) a browser app (Angular), (b) a server WebApi (ASP.NET CORE), and (c) and an identity/access control service (Google, Facebook, etc.) you certainly do not need any additional applications that run ASP.NET Identity or IdentityServer4. Seems like it would be easier without them.
If your Angular app is actually in an ASP.NET MVC, then the same is true.
If your Angular app and your WebApi are all part on one ASP.NET project then the same is true and all you need is an identity provider to return an id_token.
Related
I have the following environment
IdentityServer 4 (STS)
ASP.NET (Web API)
Angular (SPA)
My goal is that after authentication in IS4, the user will be returned to the SPA application and also there will be an additional request to the Web API, to provide additional Claims. The values of these Claims will depend on what is currently in the database to which the Web API is connected. I need these Claims in future to allow access to certain APIs
I know that this can be done through ProfileService. But in this case IS4 should be a part of Web API (which I can't do by requirement)
How should I do it right?
I had an idea to create in my Web API a new endopit, which will return a set of Claim. And these Claims I will store on the SPA side of the application in localstorage. But this doesn't seem very safe to me, because anyone can change these Claims
I'm currently in the process of implementing security on my ASP.Net Core 2.1 React/Redux app and I've been following the Js Client quickstart as well as the other Identity Server quickstarts. I've also been reading up on the concepts mentioned in Identity Server 4 + Identity Framework + React Front End and following the pluralsight course Securing ASP.NET Core 2 with OAuth2 and OpenID Connect which goes into oidc in the context of IDS4 a bit deeper.
During this pluralsight course the author goes into OpenId Connect flows (here if you have access) and from what I gather I'll need to use the Hybrid flow for Confidential clients and long-lived access through refresh tokens due to roject requirements but the author discusses potential security flaws this would introduce on the client-side. The reason being I would require a clientsecret, and a JavaScript app can't safely store one as it's a public client.
So here's my confusion, my client side app is built using VS2017's project template for creating an ASP.Net Core app with React and Redux - so is it still a Javascript App? This Web App will login through a single Identity Management Source (IDS4) and will need to grant the client access to the web project (React +.NET Core) as well as the WebApi (through controllers on the web project), so is there a way to SECURELY use the Hybrid flow to achieve this?
NOTE - the index page rendered by the ASP.NET side of the client is an html file, would it be more secure if this were rendered as .cshtml with security on this root page? What's the best practice here for security?
The recommendation for a pure JavaScript app is to use implicit flow which is what the oidc-client-js library supports. It’s the best fit for that architecture and supports automatic access token renewal but it’s not completely without its downsides - specifically being vulnerable to token theft via XSS.
You could use a server side hybrid flow combined with a cookie for backend auth but then you’d have to mitigate against CSRF.
We have a Asp.Net MVC 5.0 project which uses AngularJS for front end. The project has WebAPI Controller in the same project and it is deployed to same website. The application is built with Individual User Account project template and uses Asp.Net Identity and Claims. There is file upload module where users upload some 100MB+ files that goes through webapi and ng-file-upload plugin. Due to increase in user base we wanted to quickly improve the upload speed by separating API alone into a separate site in a new server and scale it when needed. Since API controller is currently under ASP.Net MVC solution which uses OWIN cookie authentication the API is authorized by the cookie authentication middleware.
What is the quick way to get the API into a separate site? I beleive we need to implement OAUTH token based on the MVC site and make the new API site to consume the token by enabling CORS. If we do this we are not sure if we need to remove cookie based authentication and re-implement authentication using the new token based authentication. Are there any other approach we can take here by still using cookie based authentication for the Asp.Net MVC site and separating api into a new site?
Note- We also plan to build Mobile app using this API so we believe we have to separate the webapi into a separate site and bring OAuth token based authorization.
Thanks in advance!
Regards,
Bala
If your mvc site is going to be only client side code only without any major back-end c#. This requires no security as your data comes from API which is what needs to be secured. If you dont want to seperate the two in different domains. Angular will need to read the user information being sent from the server which is why HTTPs only encrypted cookie will not work. If they are going to be different server and domain, plus you need multiple consumers of the API, you should move to oAuth and bearer token based login with refreh tokens and the whole thing. This way you can scale the api into multiple load balancers and still use the bearer token and this would be stateless. That being said you can still achieve this with cookie by storing the token in cookie that way, angular can parse and use the values and the api can validate the signature of the token and use the values. With them having to be on the same domain so they can share the cookie. This can be done without using cookie and simply using LocalStorage as well.
On an ASP.NET Core project with EF Core and ASP Identity I have 3 applications:
Web API
It will be accessed by the Angular 2 application.
In the future it will also be accessed by mobile applications.
ASP.NET MVC as a container for an Angular 2 application.
ASP.NET Core Auth with Identity Server 4.
I have a few questions about using Identity Server 4:
The Auth application should be Console or ASP.NET MVC?
Where is the Login page?
Centralized in Auth application so Auth would be ASP.NET MVC / Angular 2?
Or a login in the Web Application and one in the Mobile Application?
In case the login page is centralized in Auth application as MVC/Angular2:
3.1. In the login page I might need to display a phrase from the database.
So the Auth application can call the API in that case?
3.2. How does the Auth application verify the username and password?
Does it access the API to verify it or access directly the database?
1) Not sure what you mean by "Auth application" but IdentityServer4 is middleware for ASPNET Core. So it will be your central authority for issuing tokens for authorization.
2) The login page would be hosted within The IdentityServer4 ASPNET Core application as a normal web page powered by MVC and Razor. There is a repository with examples here.
3.1)
You can do a database call and hydrate the view model with this message when a user gets directed to the login page and access that view model using normal MVC/razor patterns.
3.2)
This is up to you, you may inject a repository or store that verifies users and their passwords in the controller or some other service.
If you follow the sample many things will become much clearer. If anything is still confusing let me know.
I am currently working on a mobile application that will allow a user to sign in via username/password (OAuth 2.0 Password Grant), Facebook, Twitter, or Google. The backend for this mobile application is coded in Spring Boot/Cloud (Java) and makes use of Microservices principles. I have several small services that are discoverable via Eureka and make use of Spring Cloud Config for centralized configuration. They are all exposed to the Mobile device using Spring Cloud Zuul, which acts as a reverse proxy. The Spring Security OAuth 2.0 setup that I have takes in the username and password then returns a JWT token, this token is validated every time a request is made to the backend. I also store users locally in MongoDB and make use of Method Level Security. I want to add Social Login to my application and have it do the following:
On the Mobile Device do the OAuth dance and get an access token
Send the access token to the server, and using Spring Social create a new User locally and associate it to Facebook/Twitter/Google, and then return a JWT token that can be used to validate requests
This JWT token should be created by Spring Security, and I should still be able to use Method Level Security and have local users
Basically I want all the features I have with my custom Spring Security OAuth 2.0 Password Grant with Social Login
This is my first attempt in architecting a system, and therefore am looking forward to responses from those with much more experience than I have. I have seen many examples that use Spring Social, but all of them are for Web Apps, not for Mobile, this is where I am currently stuck at.
The questions I have are the following:
Is my suggested approach adequate? Are there other approaches that are stateless and better for mobile applications?
Is Spring Security OAuth 2.0 and Spring Social Security enough to accomplish this? If so, are there resources that I can use? I have not found many online.
Could Spring Cloud Security be used as a solution?
Should I consider using a 3rd Party provider for Authentication such as Auth0 or OKTA?
using OAuth2 for a stateless solution is in my opionion adequate, because of:
oauth2 in general is a protocol designed to be usable in every client, which is able to perform http requests. Since the social nets you mentioned all support OAuth2. If everything goes bad, you still can consume them manually respecting the oauth2 specs, which they implement.
in general I see a problem with "authenticate with XXX and use that token as JWT for my requests". This is not directly possible, because that token is for their resource servers. Instead you need to separate 2 processes: authentication and authorization. In short you can use the socials endpoints to authenticate a user in your backend, which leads to a second oauth2 generation from your authorization server. This can create a JWT using all features from spring-oauth.
This libary should used in addition, since it helps to setup a application wide security solution. As example, you keep an own authorizationserver (which authenticates using social login) and several resource servers. spring-cloud-security helps to build things on top of that, as Zuul SSO, hystrix+ribbon powered feign clients respecting oauth2 authentications and so on
I don't thing this will help you, because those services primary serve you as an identity provider, while you are going to couple your users identity over social networks
I hope I could clarify your question in some way
I have achieved it by referring two spring example applications. Check this
steps, you will be able to achieve social sso login with Zuul, Auth-server and multiple back-end REST projects.