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.).
Related
I have Web APIs built in .NET 6 and has JWT authentication in place for security. As far as I know, UI client application uses to send userName/password as first request to API and then API will validate the credentials and send response back to client with JWT token, from there client application uses that token for any subsequent requests. In my case, client will not be sending explicit userName/password as it's UI is being launched by SSO. So in this case my API will not receive user validation request and no JWT will be generated. I am confused now, how and when will I generate token for client to use other API endpoints for fetching data from my API. Any idea/suggestions please.
Or shall I change the authentication process to any other which is suitable to my scenario. Thanks
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.
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.
I am trying to wrap my ahead around using JWT to secure a WEB API written in C#, but am getting hung up on a few things. From my understanding the flow should be something like this:
Client provides username/password to the Web API from some client application (Angular, .NET, Mobile, etc)
The Web API validates that the username/password is correct and then generates a JWT (JSON Web Token) that contains the user's roles, information, expiration date, and other relevant information.
The JWT is sent back to the client application.
The client application hangs on to the JWT and sends it with future requests.
Assuming the above is correct (and please let me know if it is not), I am having trouble understanding the following things.
Once the Web API has validated the username/password and created the JWT, how does the JWT get passed back? Do I somehow add it to an HttpResponseMessage object? I can't seem to find a clear answer on this.
How should the client application pass the JWT back? Is this in the JSON data, appended to the URL, added to headers?
I see plenty of tutorials referencing OWIN and OAUTH. What are these and why do I need them? I am holding the user credentials and roles in the database used by the WEB API.
Once the Web API has validated the username/password and created the
JWT, how does the JWT get passed back? Do I somehow add it to an
HttpResponseMessage object?
Common practice is on success, the response from the service has the status code 200 OK in the response header, and token related data in the response body
200 OK
Content-Type: application/json;charset=UTF-8
{
"access_token": "NgCXRK...MzYjw",
"token_type": "Bearer",
"expires_at": 1372700873,
"refresh_token": "NgAagA...Um_SHo"
}
How should the client application pass the JWT back? Is this in the
JSON data, appended to the URL, added to headers?
Using the access token to make authenticated requests
Now that you have a token, you can make authenticated requests to the API. This is done by either setting the HTTP Authorization header or query string in the request depending on how the server is configured.
in a header
Authorization: Bearer NgCXRK...MzYjw
as a parameter
GET http://localhost:35979/v2/endpoint?access_token=NgCXRK...MzYjw
I see plenty of tutorials referencing OWIN and OAUTH. What are these
and why do I need them?
OWIN — Open Web Interface for .NET http://owin.org/
OWIN defines a standard interface between .NET web servers and web
applications. The goal of the OWIN interface is to decouple server and
application, encourage the development of simple modules for .NET web
development, and, by being an open standard, stimulate the open source
ecosystem of .NET web development tools.
OWIN OAuth 2.0 Authorization Server
The OAuth 2.0 framework enables a third-party app to obtain limited
access to an HTTP service. Instead of using the resource owner’s
credentials to access a protected resource, the client obtains an
access token (which is a string denoting a specific scope, lifetime,
and other access attributes). Access tokens are issued to third-party
clients by an authorization server with the approval of the resource
owner.
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.