We have a large stateful Symfony 3.4 web app that stores sessions to the database.
We are looking to gradually move to microservices and we have started by creating an external authentication service in node.js
Part of the optimisation is to remove the user authentication/authorisation from the session in the Symfony app, and initially store the user authentication on the client browser using the JWT stored in a cookie on the client, with a view to potentially storing the user roles/authorisation in the JWT.
There seem to be a number of articles against implementation of JWT for this, and that we are susceptible to CSRF attacks etc, but these articles seem to be old and there are other guides insisting it is safe.
Are there alternatives to using JWT to achieve a stateless approach using Symfony, but still passing through Roles and other data?
Related
I work for a company that supports many applications, but for ease for users has an OAuth OIDC Single-Sign-On (IdentityServer4) so they can log in once and access many applications of ours. I have no problem configuring authorization to this OAuth with the returned JWT/Access Token.
But because our support footprint is so large, we have been told to handle roles, and user permissions at the application level. Here is where I am asking for feedback. I am currently developing a new API in .Net Core 6 (newbie to building APIs), and am wondering best practice for connecting a essentially third party OAuth, but also utilizing roles and permissions specific to the application.
The Identity Server returns a JWT/Access Token that is passed to API in form of bearer, but I need a mapping on the .net core backend to map the User contained in the JWT with a user within the application. Then the application can have separate mappings for roles/permissions, and utilize those roles as restrictions within the API, but I am not sure what best practice would be for this that also maintains the best security, while also achieving best performance. My thought was creating a middleware that creates and overrides userIdentity, but with that happening each call seems like unnecessary overhead. The other option is dual auth with cookie based auth that is set once, but am just unsure of best way, or what others have had success with. I know this must be a common flow that I am overthinking. Any insight is greatly appreciated.
It is common in many mature business systems to integrate identity and business data as you describe. There are two main techniques:
Identity system reaches out to business data at the time of token issuance, to get custom claims to include in access tokens. This Curity article explains the approach.
APIs look up custom claims, eg from a database, when an access token is first received, then cache custom claims for subsequent requests with the same access token. See this .NET code of mine for one way to do this.
In both cases the end result should be that the API business logic gets a useful ClaimsPrincipal that enables the correct authorization, as in this example class.
Finally, from an information disclosure viewpoint, aim to avoid returning detailed claims in JWTs to internet clients. It is common to use opaque access tokens instead, as a privacy preserving pattern.
Hi I am building a centralized authentication structure for all our applications in our intranet.
I have tried using a Jwt Web Api.
I have tried Identity Server 4 OpenConnect
And now i found out Cookie Sharing from Microsoft docs
https://learn.microsoft.com/en-us/aspnet/core/security/cookie-sharing?view=aspnetcore-2.2
I can't decide even after reading so many articles already which one should i implement.
The cookie sharing sounds very simple to do, I downloaded the sample and it worked right out of the box.
The identity Server 4 samples all have some problem that i can't run. Some functions like log out won't work or only works on one end.
The Jwt Web Api wasn't very hard to implement but still requires to thinker a bit to get claims from the token and then implement token refresh.
The cookie sharing i just found out but i'm still open for more alternatives or pros and cons each of these.
I also heard about OWIN but still don't understand exactly what it is
AFAIK
Cookie Sharing
If all of your applications are on the intranet and are all made using the dot net stack. It makes sense to take advantage of the sharing cookies. I previously had success implementing SSO using this strategy where the main login would be an old web forms application and it would authorise a dotnet core app.
Pros: You are using the Microsoft stack, easy to setup.
Cons: You are locked to using the Microsoft stack. Falls over if you want to use with native/js applications.
IdentityServer4
Having experimented quite a bit with this library, this is an abstraction of the OAuth2 and OpenIdConnect protocols, essentially authentication and authorisation using jwt tokens. IdentityServer4 allows you to specify your authority (AS => Authentication Server) which is handles authenticating clients (your other applications be it .net, js or native). The token that the AS gives the clients are then used to determine if the client has access to the an API. You get to specify which clients can access which api's and how much of it can they access based on Claims. It is possible to convert Active Directory groups into claims and authorise by that level.
Pros: Really good abstraction they simplify a big part of the process. You can secure any type of client (js/native/.net).
Cons: You still have to learn OAuth2 & OpenIdConnect specs, which can take quite some time. You'll probably endup writing quite a bit of configuration depending on how big the network of apps that you are trying to secure.
JWT Middleware
This just allows the api to authorize tokens against an authority, and it doesn't really provide the "centralized authentication structure", you will have to handle alot of the flow setup your self. generally just a watered down version of IS4.
Pros: fast and simple way to secure an api to an already existing Authority.
Cons: Doesn't allow you to create a Authentication Server.
Summary
I'd say go with Cookie Sharing if you don't plan on securing native apps or js apps.
If you are setting up token based authentication read below.
Go with IdentityServer4 for long term flexible solution and if you have time to learn how to use it and set it up.
if you have an authority and don't mind doing a bit of setup go with JWT Middleware, this will be a bit more flexible than Cookie Sharing.
I have a RESTful API written in ASP.Net that implements OAuth 2 for authentication, and it's currently accessed through a web application. I've also got a legacy desktop client that accesses the same resources directly (not through the RESTful API and without OAuth, but using the same login credentials and hitting the same database). The requirement I'm trying to meet right now is to allow a user to click a link in the desktop application in order to open the web app to a specific screen, and when they do, to have the web app authenticate automatically so that they don't have to manually log into it (since they've already logged into the desktop app).
I'm trying to work out how I can handle this within the constraints of the framework. I'm not too familiar with OAuth 2 in general, but from what I understand I shouldn't share tokens between clients and there are no flows specifically for this kind of hand-off (unless I'm missing something). Worst case scenario, I could generate a temporary token outside of OAuth that's used by the web client to authenticate rather than a username and password, but I'm hoping to avoid stepping outside of what's already in the framework to do what I need to do.
So the question is this: is there some decent way built into the OAuth 2.0 framework to handle this sort of "handshake" between two applications, or should I just build my own method of dealing with it?
Using temporary one-time tokens is actually part of OAuth spec (authorization_code grant type). In this case this short-lived code can be exchanged for access_token (and refresh_token). You will have to implemenent generating and validating of this authorization_code.
If you are using OWIN OAuth middleware:
You can generate the code at separate API endpoint accessed by your desktop client app.
After receiving token, pass it to your browser and direct it to auth endpoint with grant_type=authorization_code over secure connection. Example: call Process.Start("https://example.com/ExternalLogin/authorization_code_goes_here"). At the webpage redirect user to your OAuth Token endpoint with grant_type=authorization_code.
AuthenticationTokenProvider.Receive will be called, in which you will validate your token. (Example code here).
After successful validation OAuthAuthorizationServerProvider.GrantAuthorizationCode will be called, in which you will process the authenticated user in the same way you process it with grant_type=password.
Remember that your token validation logic should ensure that your tokens are short-lived, usable only once and transmitted over secure connection.
This is sometimes called "single sign-on" if you want to research this topic further.
There is an existing mvc 3 application that is using asp.net Membership authentication (subclass of System.Web.Security.MembershipProvider). This application was only accessed using web browser.
Now, there is a need for the application to support a Mobile App, and I have already introduced WebApi 2 Controllers into the project for handling the Mobile App requests.
The problem is that I don't have a clear thought of how to Authenticate the Mobile App users.
It seems that I have to provide Token type authenticating mechanism where the Mobile App has to submit the Token (issued after authenticating) with each request. But I am not sure how to implement it (like what frameworks/packages to use), and get it working side by side with the existing MembershipProvider
So, how do I provide a way to authenticate Web Api requests, and also retain existing asp.net MembershipProvider for MVC Controller requests.
Also, if this could be done better in some other way ?
It doesn't have to be "token" that authenticate mobile users.
The notion of tokens used to authenticate webapi requests got a lot of attention because of the OAuth2 protocol that has been adopted to the .NET world by the DotnetOpenAuth and then the OWIN. OAuth2 supports multiple "flows" and what is interesting is that beside "passive" flows (where browser redirects to an external login page) there are also "active" flows (designed for active clients like mobile apps).
Thus, switching to OAuth2 means that you are using a coherent authentication protocol supporting all major scenarios.
One of the possible approaches for you (and you seem to be interested) is to adopt the token approach to authenticate webapi requests. This is possible but this means that you have two different authentication approaches side-by-side, the cookie-based forms authentication for passive clients and token-based authentication for active clients.
I would say this kind of smells.
I would rather think of a uniform approach.
Either move towards OAuth2 completely, which means you adopt DotnetOpenAuth/OWIN for both passive and active clients.
Or you stick with Forms Authentication and just enable it for your active clients.
The latter is rather simple. Instead of carrying tokens, your active clients carry forms authentication cookie. To issue such cookies, you just expose an anonymous webapi method that expects a login and password and appends a forms cookie to the response.
Assuming you clients support cookies, forms cookie issued by the server are used in consecutive requests and all you have to do is to have the Authorize attribute over your web api methods. The forms module will pick up the cookie and populate the IPrincipal for the lifetime of requests just like it does for regular requests.
To summarize:
Moving towards token-based authentication:
Pros:
in future you could easily handle more complicated authentication scenarios (like for example using external authentication providers)
token-based OAuth2 is commonly used nowadays so you can more easily integrate with other applications
Cons:
migration could cost: you first have to gain the knowledge, do some R&D and then migrate
Sticking with forms authentication:
Pros:
you already have it and you just enable it for active clients
Cons:
forms authentication is not really "an authentication protocol". This means there is no obvious way to easily integrate with external authentication providers/consumers
I am confused about authentication with BlazeDS. Most of the few examples I have found for authentication and authorization in BlazeDS and consequently Java Servlets in general make use of HTTP basic and digest authentication and realms for authorization. These examples are very simplistic and involve XML files with the user credentials rather than using a database. My past experience in web applications used form based logins and sessions for authentication and authorization, but I am not sure how to do this with Flex apps with BlazeDS backends.
What I want to do is have some way to access some service on the backend to handle authentication like an HTML form and some way to store session data in a cookie for authorization, but I am having trouble finding relevant details using cookies in BlazeDS and Flex applications.
If HTTP authentication with either basic or digest authentication is the best way, then is there any resource to find out how to authentication users with the credentials stored in the database rather than an XML file?
I am not particularly interested in web frameworks since I would like to understand how to authenticate/authorize users with a plain Servlet and BlazeDS.
Authentication with BlazeDS and Flex is no different than with traditional web apps. Flex uses the same networking stack as the browser. So just follow instructions for securing your app server and then it should just work. If you want to have the login form in Flex then you can just send the credentials to j_security_check (for form based auth). Alternatively you can call login on the channelSet. Spring Security and Spring BlazeDS Integration M2 makes this very easy. Check out the Test Drive for a great sample (the usernames and passwords are still in an XML file but you can easily following the Spring documentation to move those to a database or LDAP server).