I have a web api server on lets say, api.app.com which serves data for my app and i have a separate web server on www.app.com which serves users the pages for the app. I am using a JWT created on the webapi to Authorize the user. The token is created when the client logs in from the login page served on www.app.com with a username and a password. I want www.app.com (web server) to send a request to api.app.com (web api) to authenticate the user and then store the token gotten from the web api inside a cookie on the client.
Then i want only api authenticated clients to have access to pages on the web server, while the web server gets data from the web api on the behalf of the client per request.
I have checked everywhere online, without a clear solution to this
Web apis are usually consumers of JWT tokens. Once received they validate the token, and check claims and proceed based on the result. Your environment is a little confusing to me.
It seems your api app is used as an identity server as well as data provider. It is best to separate these concerns.
Related
I have a .NET Core application consisting of a web front-end written as a single page app in React JS and backed by a .NET Core API services app to supply it's data. They're deployed as separate applications in IIS so the urls are like this.
https://example.com/FooBar
https://example.com/FooBarAPI
I've been tasked with integrating the FooBar site with our corporate SSO which uses SAML and authenticates against ADFS. They've provided me with a metadata xml file from ADFS that as I understand it this metadata contains all the details I need to put in my web.config to get this working. I've found some good examples on stackoverflow for getting the FooBar site protected from unauthorized access and working with SSO.
But what about the API app that the javascript needs to call? How does that piece of the puzzle fit? How does the API know that the JS client is part of the same app/user and that they are authenticated to make requests for data?
How does the API know that the JS client is part of the same app/user and that they are authenticated to make requests for data?
Client registration identifies the JS client. The implicit flow and its resultant id_token identifies the end-user.
These are the very high level steps:
Register the JS client (the public client).
From the JS client, use the ADFS implicit flow to fetch an end-user id_token.
From the JS client, call your API with the id_token.
This documentation appears to match your use case reasonably well and provides a high level overview:
...when the user signs in, the JavaScript front end uses Active Directory Authentication Library for JavaScript (ADAL.JS) and the implicit authorization grant to obtain an ID token (id_token) from Azure AD. The token is cached and the client attaches it to the request as the bearer token when making calls to its Web API back end, which is secured using the OWIN middleware.
If I were in your shoes, I would first make the demo application from that documentation work with my ADFS tenant. Then, I would translate its setup to my React/ASP.NET Core app.
So we are currently looking to build out a site that utilizes a Web API for all of our authentication and communication with the database. What we are unsure of at the moment is how to persist users in our MVC application by authenticating through the Web API.
Where does this happen on the MVC side of things and how should we be authenticating with the Web API?
EDIT: Another thing I am wondering is if we can make a call to the API to get an Identity user after they are authenticated and instantiate the identity user on the MVC side of things and just store them in a session variable to persist on our application. Would this be doable and any idea what it would look like?
MVC utilizes the session for authentication. A cookie is sent to the user, and the web browser sends that cookie back with each request to enable to the server to restore the session and recognize the user as authenticated.
Web Api is REST-based and stateless. There's no concept of a session, cookies, etc. Each Web Api request must be authenticated in the request, usually by passing an Authorization header with a bearer token or similar.
If the MVC application utilizes the Web Api to authenticate, then the Web Api should return an authentication token to the MVC application. The MVC application then, should "log in" the user by setting that normal authentication cookie and save the token so that it can authenticate future Web Api requests with that. In other words, the MVC application still handles authorization as it normally does. The only difference is that the response of the Web Api determines whether or not it considers the username/password combo to be correct, rather than a database query made directly.
I would like to create a Client application in MVC 5 with a log in page on a different domain.
What I want to achieve is a centralized authentication domain for all of my applications (MVC 5 web applications, Web Api's and Desktop applications as well).
I tried to use the example below:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
I can use the token to get resources from Web Api with both client type (website and desktop application), but I would like to use the claims and properties in the website as well and reach the web api with the token provided by the authorization server.
The only problem I have is that I can't set up and MVC 5 project to redirect to authorization server domain when the user is not authorized and after a successfully authorization redirect back to original domain and use the claims and properties which are encrypted into the token provided by the authorization server.
Can you provide me a sample or some articles with which I can start implementing the upper things by usin OWIN OAuth2? Thanks in advance!
I'm developing a Web API and was looking to use Azure Mobile Services to authenticate users before allowing calls made to the Web API.
So the user would navigate to a website, choose to log in using their Google/Facebook/etc account and the user would be authenticated using the Mobile Services JavaScript client. From what I understand Mobile Services will then return a authentication token in the form of a JSON Web Token.
What I would like to do is when website calls the Web API it would pass along the authentication token, the Web API would check that it's a valid token issued by Mobile Services and if all is good, then allow the call to be executed.
So my question is...is this possible? If so, could the JSON Web Token Handler for .NET be used to perform the validation on the Web API side?
Yes, that is possible.
If you perform a login using the MobileServiceClient, you will get a token that you can pass along with every request to a Web Api endpoint.
var client = new WindowsAzure.MobileServiceClient('https://yourservice.azure-mobile.net', 'your-client-key');
client.login('facebook').then(success);
function success(result) {
alert('login ok');
}
So when making a request, set the value of header 'X-ZUMO-AUTH' to the current users token you find in client.currentUser.mobileServiceAuthenticationToken after a successful login.
On the server side, add the attribute [AuthorizeLevel(AuthorizationLevel.User)] to Web Api methods that require the user to be authenticated. Thats all.
But make sure, that identity is configured properly on WAMS, and also at the provider side you want to integrate (client id's, client secrets, callback urls, etc.).
I am about to start working on a new ASP.NET MVC web application that I intend to build an iOS mobile version of as well.
I am planning on using MVC 4 Web API as a service layer that will sit in front of the business layer and be accessed by both the web application and the mobile application.
I am a little confused however about how I will implement authentication and authorization in this architecture.
Normally in an MVC application, once a user submits proper credentials, I would make a call to
FormsAuthentication.SetAuthCookie(username, false);
Which will create a cookie that will then be passed back and forth from one request to another to maintain a user's session in the application.
I'm confused as to how this will function through a service layer when accessed from the web application. Or how it will function when the service is called from the mobile application.
You could design your Web API in such a manner that it would require the forms authentication cookie should be sent on each request. You would then use this cookie to extract the username of the currently authenticated user from it.
But when designing an API it is usually better to use some other means of authentication than cookies. For example you could use the Authorization HTTP header where the client will be required to send the encrypted value of a forms authentication ticket.
You might also take a look at the following article about token based security.