We are developing an MVC application which links to a Web API. Currently, in order to do any calls to the API, the Javascript makes an AJAX call to the API sending a username and password for authentication. The API validates the username and password and sends back a security token. Then a second AJAX call is made to do the actual business logic, sending the security token with it.
We want to move away from this method since exposing the username and password in the Javascript is a security hole.
What we're looking at is a way to get the API to recognize where the call is coming from. For example, if the call is coming from our website, it's legitimate. Otherwise, the call is denied access.
Is there a way to do this? If so, are there any online walkthroughs on how to setup the API to do this? Thanks.
Related
I am working on Xamarin Forms application and new to providing login authentication of the application. I have completed the design part of the application with using Entries for user id and password and button for Submit. Also, i am having web API and for authentication. Now how to connect that Web API in xamarin forms application for login.
Please guide or provide some use full samples...
Thanks in advance...!
I assume you've built out your authentication API already, and that you can make Fiddler or Postman calls directly to your controller, pass in a set of credentials, and return back a JWT / bearer token that you can then use for authenticated calls?
At this point, it's relatively simple then as you'll want to use build a proxy layer / API layer to make calls out to your API. These calls will simply mirror the ones you've made in Fiddler/Postman/your proxy of choice.
I used Refit to achieve this:
https://github.com/reactiveui/refit
Specifically, you can see on the "Setting request headers" section how they easily encapsulate it for you to pass your token.
Of course, your initial call should be to login, and then once logged in, take the JWT response back from your controller, set the token in your Keychain, and then pull it out of Keychain to set in the header.
Let me know specific questions you have? For example, which of the following do you need more info on?
Sending and parsing a response (serializing the response) from your Login action to set/assign a token in keychain?
Saving the token, and setting it in a header for subsequent calls?
Building a proxy layer using a framework like Refit to make generic outbound calls?
There are SNS application with 2 servers. Web backend server and REST API server.
The web server allows user login/logout with username/password, and show user information
The REST API server provides APIs like /topics, /comments, it should be stateless without session
The REST API will serve other web applications
There are some potential solutions, but neither is security.
Base Auth, the browser hold the username/password
Token with expiry timestamp, the problem is user could stay on the page until token expires
So, is there a way to protect the REST API when calling it from AJAX?
If I have understood your problem correctly I may suggest you use the Token solution. In order to maintain security you may generate new token on every request (& send it to client in response), which should be used to make next request, and disable token if it is once used or has expired.
Sorry, I meant to mention it as a comment, but I don't have enough reputation.
I created a WEBAPI solution and I am creating the HTML pages to access all the functions of that web service. I am using http basic authentication.
I got these options
Save the username and password in a Javascript vars and send them every time I call any of the WEBAPI functions.
Send the username and password the first time, create a token on the server and send it back to the client, then save it as a cookie and use it every time I call any of the WEBAPI functions.
Dont use HTTP basic authentication.
What is the best way to handle this?
Thanks
You don't want to send the username / password on every call for security reasons.Token based authentication would be the way to go and you can use the built in identity authentication for that.
The best tutorial I have found for that is http://bitoftech.net/2014/06/01/token-based-authentication-asp-net-web-api-2-owin-asp-net-identity/
There's nothing wrong with using basic authentication as long as it is done over a secure channel. If you send the username and password on every call, your api will need to access the database on every call just to authenticate the user. If you send a token when the user is authenticated, then you remove the need to access the database on subsequent calls.
Using a token also allows you to take advantage of an identity provider such as Thinktecture's IdentityServer to provide single sign on. If you have more than a few systems, it will allow users to log in one time and then access any of the applications and it can greatly simplify security.
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).
We have a web-based application in which we are not requiring end users to login. The application uses Ajax to make calls to REST services hosted on the same server. Besides this application, we want to make sure that if any other applications / agents call the REST service they get denied.
What is the simplest way to secure a REST API like this? My guess is that we would include some sort of security token and make the call through HTTPS. However I'm not clear how the Ajax application would create/obtain/encrypt the token and generally what the lifecycle looks like.
I would rather do this outside of Spring Security or OAuth if possible. I have also read that sending username and password over SSL is enough for authentication. In this case, the app would have a "username" and password and it would send it with every request to the REST service. But how would it keep that information secret if the client is just HTML and javascript in the browser?
Thanks.
In general this is impossible. Someone could just do view source on your javascript, read the token, then do whatever they want.
https is not necessary here. For the token, probably the easiest is to set a cookie when they download the javascript from the server, then that cookie will also be transmitted with any AJAX requests.
This is not really secure - anyone can just see what the cookie is and use it, but it's the best you can do.