Trying to search for this results many many results for securing a WebAPI and how to secure an MVC application, but i could not find a solution.
What i want to achieve:
i have an MVC website with a modal Login form,
When the user enters he's credentials to the the form, an Ajax request is sent to a WebAPI with the credentials.
The WebAPI should return (i guess a ticket, since that is what i found).
The ticket would be then saved into the sessionStorage of the browser (no cookies),
Each page request to the website will check for the token, and enable/disable the parts that need to be secured.
All the examples i have found are showing either MVC only authentication,
or WebAPI authentication, but i could not find anything that does the described above.
The sessionStorage is available only for client-side use. You can manipulate or retrieve values from the storage using Javascript, but you can't directly read data from the server. Since MVC typically renders HTML Views server side, you have no options to send the token stored in the sessionStorage on each request.
The situation you described is an hybrid solution which can't be achieved without the use of cookies.
A simple solution is to set the login data (specifically the token if you will use a token-based approach) in a cookie issued by the Web API endpoint during the login phase.
Related
I have the following setup:
1) WebAPI that accepts JWT Bearer tokens for auth.
2) Portal (WebApp) that puts a nice face on the json output from this WebAPI. It does OpenIdConnect authentication and uses Cookies to persist login information. It is an ASP.NET Core MVC app.
3) The WebAPI and WebApp are on different domains.
4) The WebAPI layer is designed to be called by any 3rd party who can present a valid token - either via App auth (client_credential flow, for eg) OR Delegated User auth (implicit flow, for eg). The WebAPI also does RBAC auth.
At this point, the problem I have is this:
1) I want to be able to make AJAX calls from the WebApp controller pages (cshtml) to my WebAPI so that the pages are responsive and there are no POSTs. So I integrated ADAL.JS into the page for that purpose. It works from a functionality pov.
2) HOWEVER, this results in multiple authentication dialogs (web page popups).
-- 1st auth popup. Upon navigation to the Portal homepage, I get challenged and have to enter my credentials on my company login page (federated AD auth).
-- 2nd auth popup. Then when I invoke anything on the Portal pages that involves ADAL.JS (namely the AJAX calls), it causes another login dialog because ADAL.JS cannot see the login cookie from ADAL.NET layer. This dialog comes up and goes away without any input needed tho (because the cookies from (1) are sent along to the server automatically by the browser). At this point, I have the ID_TOKEN and an ACCESSTOKEN for the PortalApp's client_id show up in the ADAL localStorage area.
-- 3rd auth popup. Then another dialog pops up; it uses a Hello pin login (I assume this is due to 2-factor auth requirement enforced by my tenant). At this point, I see the ACCESS TOKEN for the WebAPIApp's client_id show up in the ADAL LocalStorage area.
And now my AJAX calls start working.
Is there a better way to do this so that I can get the benefits of AJAX and not have to resort to serverside POSTs and have only 1 auth dialog instead of 3?
(I thought of may be switching ALL authentication to be done by ADAL.JS for the entire site, but I like the paradigm of using the [Authorize] flags and RBAC for the Controllers. OR is there a way to make my WebAPI accept both JWT and Cookie authentication?
Thanks!
I am developing an ASP.NET Core Web Application using a combination of MVC Views and Web APIs. I also use Identity for user management.
I now want to enable Anti-Request-Forgery Tokens for our Web API. For that, I use the IAntiForgery service in Razor views to GetAndStoreTokens and forward the RequestToken to a $.ajax call as a header, as described in the official documentation in section JavaScript.
When I run the corresponding page that performs a Web API request with the user being signed in (Cookie-Authentication), I can also see that the request token is set properly as an HTTP Header (see orange box in image). However, the Anti-Forgery validation of ASP.NET Core denies the request with the following message:
Antiforgery token validation failed. The required antiforgery cookie ".AspNetCore.Antiforgery.ybHEizTXFmU" is not present.
Thus, the cookie-part of the Anti-Forgery-Token (blue box) is the problem here - the key starts with a different ID: .AspNetCore.Antiforgery.lUjKpn5xN20 instead of .AspNetCore.Antiforgery.ybHEizTXFmU
How can this happen? The Web App and Web API reside in the same process / at the same domain, so no Cross-Origin-Calls are performed. Is this a problem of $.ajax (which I can't explain because the browsers cookies of the target site should be reused) or a problem within the ASP.NET Core Anti-Forgery (or even Identity) module?
Currently I have created a WebAPI Project using identity framework and I have setup tokens to be returned when authenticating with the API.
So now I am looking at creating a standalone MVC application that will allow the user to make calls to the WebAPI to get back end data.
The goal is to separate functionality so that other applications can also start interacting with back end data through web calls.
So the confusion now is how do I setup my MVC project so that I can use the Authorize attributes on controllers with the token received from the WebAPI. I think I need to enable bearer tokens in the ConfigureAuth method in Startup.Auth.cs. However will that be sufficient enough? Or do I also need to enable the cookie authentication?
MVC and Web Api are fundamentally different when it comes to authentication. With Web Api, the bearer token has to be set in the header of the request, but this is not an issue as all API requests are done programmatically by the client, i.e. there's human-intervention involved in setting up the client to authenticate the request properly.
MVC is a different beast in that the actions are accessed generally via a web browser, which will not automatically affix a bearer token to the request header. What it will do is pass cookies set by the server back to the server. That's why cookie auth is used most typically for MVC web applications.
What you should do is enable cookie auth for the MVC site and then set up your sign in action to authenticate via the Web Api. When you get back a valid auth from the Web Api, then you can manually sign in the user via the Identity API:
await SignInManager.SignInAsync(user);
I followed this code and implemented the jwt authentication successfully. I am using this authentication in my web application. I am able to get the token on the login page. After that how to attach that token to the header of all the subsequent requests. I stored the token in local storage, but when I navigate to next page after successful login before js loads, the page getting loaded with 401 error.
How should I achieve this?
The problem is you're trying to use token based security with the Web MVC architecture. I did a quick search for any tutorials on how to do it that way and all I was able to find is examples of REST APIs that use token based security.
The reason is that with Spring MVC, each link you click is going to redirect you to a controller endpoint that is going to render the HTML and send it back to the browser. Unless you somehow made every link on your site include the token in a header or perhaps used a cookie to store the token, you'll get a 401 error because the token isn't present in the request.
If you were to use Angular JS (or your favorite front end framework) with a REST backend, you'll be able to use the JS to put whatever you need in the header to make sure the user is authenticated and has access to the resource. There a lot of example projects out there that demonstrate how to do this.
Disclaimer I haven't been able to find a reliable source that definitively says that token based security is for REST only. I'm basing this on experience and readily what I see out there in terms of tutorials and how to articles.
Ich totally agree to the answer from blur0224, you have to set the token in the request header of every link on your pages. I don't know how to achieve this. Furthermore I think that JWT token based authentication is not the right way for MVC based app. I would use it in SPAs build with frameworks like Angularjs.
Why don't you use the 'standard' Spring authentication?
I have been playing with Thinktecture IdentityServer3 and am keen to use it as the product looks great. However, I don't fully understand how to accomplish my flow which is probably fairly common:
Create Identity Server using Implicit flow
Setup an MVC web site
Setup a separate Web API
So far so good, as demonstrated in the examples on the site. I now wish to call the API using AJAX calls directly but for this i need an access token. It seems like a large overhead to have to route these through the MVC site itself (again, in the examples).
How can I accomplish this flow? Would it essentially blend the MVC and Javascript Client samples or is there a smoother way so the user only has to sign in once? Perhaps send the access token in a hidden field but then how would it renew?
Any help on understanding this would be great.
I've managed to come up with a solution which seems to work, not sure if it's best practice though...
Expose a method on the MVC site at AJAX/AccessToken
Method should be locked down with Authorize attribute to ensure the MVC part of the site is authenticating properly with IdentityServer
Method returns the users Access Token which was generated through the above call via MVC controllers
In JavaScript, simply use this endpoint to get an Access Token and then call the API manually
The call to get the Access Token should be secure as its within the same domain/authentication model as the MVC site itself
I've put up a sample here for anyone interested:
OIDC-Website
Check out the form post client to see the endpoints being called explicitly. You will need to hit the token endpoint to get your access token.
You should be able to use these endpoints in your AJAX calls, store the received claims and tokens in a cookie and take it from there.
Note that to renew the access token, you will also need to store the refresh token. The Implicit flow does not allow for refresh tokens (you'll need to use the Authorization Code Flow or the Hybrid Flow).