I have a WCF application where I make JavaScript calls to. I want to secure the web services so you have to be logged in to use it. This is easy if I have a server-side application making the requests to the WCF. If I am using a pure JavaScript / jQuery client-side app, I can authenticate fine by passing the credentials as JSON parameter, but how do I keep that client-side app logged in from that point on? Do I store a cookie? I do not want to store the credentials in the cookie of course because that is not secure. So how can I achieve this without introducing another server-side application to the mix? How do web apps achieve this?
OAuth is kind of the go to solution for JS API's. Netflix, Yelp, Facebook etc. use this.
Here is an article on OAuth in WCF
And here is a pretty well known library for doing auth in .NET: DotNetOpenAuth
If you use or are using ASP.Net form authentication (WCF should be running in ASP.Net compatibility mode) then there is not much to do.
If you set the form authentication ticket\cookie after your initial authentication, the cookie would be attached to every subsequent request from the browser without you writing any code. All future calls to WCF service then can be authenticated on the server using the standard ASP.Net authentication pipeline.
Related
I am writing a React.js non-single page application. I've been using auth tokens to store my authentication sessions which normally works fine with single page applications. But in my case, whenever the client makes a request directly from the address bar, I can't execute the js code that places the auth token in the header of the request.
I would prefer not to use cookies to handle this problem, especially if I plan to convert my application to a single page or isomorphic application. Is there another way to maintain sessions in my application?
This isn't specific to React.
You can use JavaScript as you were doing to manipulate custom headers, browser cookies, or URLs with custom query strings.
If users may type directly into the address bar a URL on your web site, you need to use cookies. The browser will automatically send them with each request. Using cookies is a common technique and shouldn't cause a problem if you move to a SPA or isomorphic application.
Cookies are your best bet becuse the browser will transparently send them for you. They also work with hybrid mobile platforms (phone gap, etc). And yes, cookies ARE secure if you use them the right way. I've elaborated on this issue in my blog post here: Token Based Authentication for Single Page Apps (SPAs)
I am developing a RESTfull web services. This web services will serve as a Web API to the outside world to get some data from our system. So, it will be consumed by other external clients: Mobile Apps, JavaScript clients, etc. For security, it will require Basic HTTP Authentication: user name and password sent as clear text over HTTPS.
So, I want to put together a proof of concept JavaScript application to demonstrate how one would use this API. But I don't want to hard-code user name/password in JavaScript code, since it can be viewed in page HTML source. In fact I don't want JavaScript to be involved in Authentication at all. So, I was thinking having another web page for server to server authentication. So that client's server sends credential to WEB Appi server, then Web API server issues a token valid for one session only, after that Client server uses this token in JavaScript.
Is this the right approach? If not, what's the "best" solutions for this scenario? I am sure this was done before. Any articles, or code samples will be much appreciated. Thank you
I'm developing a backend service in Grails that should serve both a web application and a mobile application.
The frontend is being developed using AngularJS and the mobile app will use the same AngularJS codebase to go native with PhoneGap.
Now, I'm looking for a proper way to implement the authentication with the Grails backend that works both for the web app and mobile app.
Three ideas:
1) Store username and password in LocalStorage and authenticate the user on the backend at every request
2) Use cookie based authentication (it's tricky to enable cookies in PhoneGap, I should
extract from the AJAX response and attach in the AJAX request)
3) Develop a custom protocol that generates a token for every session in the backend and stores that in LocalStorage. The session token will be sent in every request to the backend.
4) Sign every request using a private/public key mechanism (similar to Amazon AWS). Even in this case, the backend has to verify the correctness of the signature for every request (there is not a session concept).
I don't trust the LocalStorage so much but I have no other ideas and I can't find any example (an example with other backend and frontend technologies would help the same).
You can assume that the backend will run on HTTPS.
I would go for the third one, with some additions:
The first time the device is connected, you authenticate the user in some way (user/password or whatever). Then you send a persistence token to the device which saves that to the LocalStorage.
For each following session, upon opening the client exchanges the persistence token for a short lived session token (how much short lived is up to you, depending on the context).
This is similar for what you provide but reduces risks of man-in-the-middle and replay attacks.
Hope this help!
I am building an API and had questions about handling authentication when using a front-end framework such as Backbone.js.
I have a single API server that is responsible for returning and modifying data based on RESTful web requests.
I have another app server that is a Backbone application. I want this application to connect directly with my API server, so set the entire project up so that this app server can make cross-domain AJAX requests to the API server.
There are some API routes that I do not want unauthorized parties to obtain access to. For example, I have a path /users that lists all the users of my app. I need this path later on for admin functions, but I don't want it publicly available to my app server.
What is a good authentication scheme to use? OAuth won't work because the secret token would be exposed on the front-end. And after that, I'm a little stuck with what my options are. Does anyone have any suggestions moving forward?
In cases like these I use a combination of techniques.
-- Good ole Cookie based auth
As a backbone app will always be used inside a browser and browsers have built-in cookie support, I would suggest that you should accept cookie based sessions on the server side. All the auth related stuff will be handled by the browser and you don't have to worry about storing keys etc. On top many libraries like (NSURL in iPhone) and frameworks (like PhoneGap/Trigger) all support cookies so woha you can support all kind of clients with litte work.
-- Plain API Key
For third-parties, I use api-key based authentication. You provide username and password, I provide key. You send me that key every time in HTTP header for all subsequent requests. I use the key to identify you and then allow/disallow actions accordingly.
I assume once you can authenticate a user (wait..who are you?), then you can setup authorizations ( you say Micheal ? ...ok you can access /users )
Also take a look at my backbone-parse plugin for an idea on how to authenticate users against an external API service #shamelessplug
I'm looking for a nice pattern that woud help me to fully sign my api calls with javascript (here for some example, vimeo) after some oauth connect retrieved authorization identifiers.
Using ruby with omniauth, what I'm looking for would be to retrieve the url that gets called when you do a ModelName.{generateTokenMethod}.request(:get,{url})
It is possible. There are a handful of oauth 1.0a libraries for javascript (You could try looking at some node.js code as an example).
The problem with using oauth in client-side javascript is that it will expose your client secret to anyone using your web service.
Anyone who has your client secret can make requests on behalf of your application, and lure users into generating access tokens by masquerading as your application.