I am using IdentityServer 4 with ASP.NET Core 1.1 and Angular 2.
I need to access the API from 3 different sources:
A mobile application;
An angular 2 application which is contained on a ASP.NET Core MVC;
In the ASP.NET Core MVC controllers.
Which GrantTypes should I use for each one?
The API itself doesn't have a GrantType, rather it simply consumes tokens (JWT or Reference).
For a mobile application, the usual security concerns of securing credentials in a client-side app applies. In other words, a flow which doesn't require a client secret, and ideally, doesn't give the user the actual access token. Authorization Code / Hybrid Flow meets this criteria. The limitation of this approach is all communication would need to be proxied through the server hosting the access token.
Since it is contained in ASP.NET, cookies are an option. Implicit Flow or Authorization Code / Hybrid Flow would work well here. Use Authorization/Hybrid if you need access to refresh tokens.
Same as #2
For more detail, Auth0 has a great guide:
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
In reverse order...
3. Authorization Code (because your secret doesn't leave an environment that you trust)
2. Implicit (because your code does leave an environment you trust - i.e. runs on the client's browser, so any secret would be accessible)
1. For me, implicit, because you can't really trust the mobile environment (i.e. the code could be reviewed and your secret compromised). However, you could use authorization code, but if you do, your mobile secret should be different from the MVC secret.
You could also consider Hybrid for the MVC & mobile flow, as that will use server to server communication for the access token exchange.
Related
I'm building a React SPA on top of a ASP.NET Core API and I want to authenticate with OIDC. Grant type is authorization code and the client does have a client secret.
Since we will be using a client secret, the authorization step that involves the secret has to go through a proxy that we control.
Is this doable in a React SPA with oidc-client?
If the secret is in the client, it's not a secret. :)
Secrets are for server-server authentication, because the secret is secure on a server (we hope so, anyway) and the API granting access has a whitelist of consumers it's granted access to use the secret.
For a SPA, if you're talking about allowing an app to use an API, I believe you're limited to using a CORS whitelist. If you're talking about a user accessing the API via the client, then you're looking at access codes and usernames/password.
PROBLEM
You have a blocking issue with the authentication system, or with usability or getting security to an acceptable level. In your case there is no PKCE support.
PROXYING SOLUTION
Use oidc-client which will add PKCE parameters and your SPA security supports the latest standards.
The client secret will come into play during the authorization code grant and refresh token grant messages.
Messages can be adapted server side to remove PKCE and use a client secret instead. It is quite a complex solution though and not everyone will like it.
It requires a SameSite cookie issued by the web domain. In my case I used an AWS lambda edge function that runs within a CloudFront content delivery network.
WHY DO IT THIS WAY?
In order to fit into an SPA architecture and meet wider goals in areas such as usability, coding model, mobile integration and global web performance. Depends if you feel it is worth the effort.
LINKS
Architecture Goals
Design Pattern
Code Sample you can run
Online AWS SPA
Proxying details
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.
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.
We are planning to implement an AngularJS web application communicating with Business components via REST service layer. The web app needs to offer authentication mechanism.
For example we are particularly concerned by the user authentication process since Angular code is practically available to the users on their clients.
And how can we reassure that the users are authenticated after the initial authentication process (in JSP/PHP we would use sessions)?
Could you please give us some pros. and cons?
Your right client side code is available, viewable, and editable thru standard browser developer tools. If your company does any type of security audits on your software you'll find that for security reasons processing is done on server side outside of the view of the client code. The companies I have worked for have taken the approach to trust nothing that is sent from the client side to the server.
On the server side the REST layer typically contains a authentication layer that will bubble back to the client when.
-invalid session
-incorrect permissions to make rest call
-invalid REST args
-prevents script jacking into text fields
-etc...
When working with angular or other client side only applications, I recommend using Token based authentication.
A demo application in Angularjs
Token Based Application
Angular JS, Web API Token Based Authentication
We are the process of developing a android phone app using IONIC framework and Web Api as the backend.
My question is ,is it sufficient to use Forms Authentication along with SSL to keep the phone app secure.
Our background is in Asp.Net web development and we could not see any examples that uses Hybrid mobile app development along with forms authentication,that makes me wonder if we are in the wrong track.
We implemented CORS along with WithCredentials both on Angular and Web API side, and the authentication piece seems to work fine for all subsequent calls in debug mode.
Do we need to take additional steps for security ,since its a phone app ?
Edit: I was reading about bearer token authentication with Web Api, is this a recommended way to go with phone apps ?
Thanks !
Yes my recommendation is to go with bearer tokens not with forms authentication.
You need to use OAuth 2.0 Resource Owner Credentials Flow which means that end-user provides the username/password only once for a specific endpoint i.e(/token) and then if the username/password valid you obtain something called Bearer Access Token.
This token is valid for specified period and you can configure this in your Web API. Once you obtain the access token, you need to store it securely in your android/hybrid app, then you keep sending it with each request to your web api protected end points using the Authorization header (Bearer scheme). I've written very detailed post which covers your scenario 100%. Please check the post Token Based Authentication and another one for authentication with AngularJS authentication which should work with your case. Let me know if you need further help.