My java/javascript web application is in development, and I hava a javascript application that communicates with my database (where I maintain my own userids) using ajax POST commands to a servlet container running on localhost, within a vmware machine. I want to be able to login using Google, Yahoo, and Facebook authentication, on this development setup, but in studying Facebook's OAuth 2.0 method, it looks like your web application has to hava a link to the facebook site, and provide a redirect link back to your own site when authentication is finished. This method won't work because facebook can't redirect to a localhost address and reach my machine, which doesn't have a web presence.
Do I have the same issues with OpenID and Google/Yahoo authentication?
Andy
Facebook OAuth works with localhost apps. This is because Facebook redirects the browser to the redirect_uri you supply in oauth, your browser knows where http://localhost is (I actually used a virtual host in apache & windows vhosts, don't know if you can enter localhost as website url in your app settings). Works perfectly
Google Oauth however, in my experience, doesn't work on local version. Somehow the site needed to be accessible from Google itself (not just the browser) for this to work, and it didn't, so it doesn't (I don't remember the exact details, sorry)
Don't know about the others
You could add DNS entries on your local machine so that mysite.com resolves to your local computer.
By doing this, you will be able to login from your local machine to do your tests.
In Windows, you can do this by editing the file:
C:\Windows\System32\drivers\etc\hosts
Add a new line:
127.0.0.1 mysite.com
Regarding OpenID, I am not sure if would accept logins from localhost URLs, but it will surely work after adding the entry in the hosts file and having a proper domain (even though it RESOLVES only on your computer).
The trick is that after login, Facebook or Google responds to your application with something like this: redirect the user to mysite.com as authenticated. Your browser then will resolve mysite.com as your machine and it is all working.
Related
today I'm developing an app for Firefox OS, but I have a problem. I would use the OAuth2 method for receiving the access token, but I don't know where redirect the page after the Authorization.
What is the path? There is any browser api that I can use?
If it's a hosted app, then redirect to a URL on your domain just like you would in a browser. If it's a packaged app, declare redirects in your manifest. Your app must be privileged to use this field.
I have a custom Node.js server using Express and PassportJS (for Google OAuth2.0 authentication). I want to build a Chrome extension that will authenticate through my Node.js server, but is still Google OAuth2.0. Additionally, if a user has signed into the website, the Chrome extension should also be signed in. What are steps I should take to accomplish this? I've taken a look at User Authentication docs but this is what confused me. My auth identity is Google since (client ID, secret are the same), but I'm authenticating through another server.
We are developing a web application that uses strophe.js to communicate with an openfire server for XMPP chat. The web application is hosted on tomcat and both tomcat and openfire reside on the same server. Strophe.js is using BOSH (essentially http long-polling) as a communication mechanism between the client and the openfire.
Our tomcat instance authenticates (form-based) using a users table in our database. We've configured our openfire instance to read out of the same table. That way mobile apps can directly connect to our chat server using the user's credentials
We also have apache running as a reverse proxy. This might be TMI for the problem at hand, but more information can't hurt. The url schemes look like the following:
http://myserver/web Our web interface. Goes to http://myserver:8080/
http://myserver/chat Forwards to the openfire BOSH url (what strophe.js connects to). Goes to http://myserver:7070/http-bind (openfire bosh endpoint)
The problem I'm trying to figure out is how to log in to our openfire server from the browser. For example, if the user goes to the login.jsp site and enters their credentials, the server will forward that user to index.jsp. The strophe.js connection will try to connect to the chat server (/chat), but at that point, the username and password is no longer available to the javascript code.
I need to figure out how to securely authenticate the user in the web browser with the openfire server AFTER authentication has occurred. I've looked around for some examples, but there's not much information out there (or rather, I don't know what to look for).
Some Possible Solutions
1.) The first strategy I tried was creating an AuthProvider implementation in openfire that can take the browser's cookie as the password, make an HTTP request to tomcat with that cookie, and if succeeds deem that user as authenticated. This worked at first, but when deploying I found that I needed to configure tomcat to allow the document.cookie to be populated with the JSESSIONID. After reading a bit about this, it seems that using cookies is not recommended from a security standpoint. Jeff Atwood has an post Protecting Your Cookies: HttpOnly that discusses the security issues stemming from cookies accessible to javascript. Although I am not completely opposed to using cookies, is there a better way?
2.) A solution I have also thought of (haven't implemented yet) was providing a REST endpoint to create tokens that the user can fetch once they are logged in and use as passwords for the openfire server. Seems a little better, but I'll need to create a new table, manage their expiration, etc.
If anyone has tackled this problem, please let me know. It would be greatly appreciated.
I have a WebSite (MVC 4) and WebService (Web API). WebSite has an authentication cookie and it decrypts that in order to send a secure token on to WebService when the WebSite server side code calls the service. That works fine.
However, the WebSite has JavaScript that I would like to call the WebService directly. I've tried sharing the MachineKey and Auth information, but the cookie is not carried across the WebApi.
My fallback is to route all calls to the WebService via the WebSite; but that's ugly and slow.
Any ideas?
The correct answer is Darin's. In order to share a login cookie between a services site and a web site, they will both have to be on the same domain; so e.g. the services site could be at
http://svc.mysite.com
And the web site could be at
http://www.mysite.com
Then the browser will allow the two sites to share the same cookie.
An alternative would be to have the site authenticate to the services site and get a token of some kind it could pass to the javascript. However, unless you were running on HTTPS this would be highly insecure, as the token would be available "in the clear".
A final mechanism (and the most common solution I think) would be to route all API accesses through the web site, but this is not ideal in many circumstances.
I am building a JavaScript SDK for our API. The API currently requires (2-legged) OAuth authentication. Obviously this isn't suitable for a JS SDK since the key and secret are in plain site (in the JS code).
Facebook only requires your app id when you init their JS SDK, so I would like to implement something similar (or of similar simplicity). When a developer requests a key we require their app's domain. I was thinking of detecting the IP address of the submitted domain (for example myclientapp.com has 192.168.0.0 IP). And then authenticating JavaScript requests by confirming the remote hosts IP address matches.
Is this the best/easiest way of doing this?
UPDATE: As Rup pointed out the remote IP will be the client and thus not match the apps URL's IP. So that's out. So to reiterate I'm looking for a solution that will allow me to enforce some form of authentication in my JavaScript sdk for my API that can't be spoofed by someone else (trying to be someone elses app).
Thanks,
Gavin
Authenticate the user instead.
Have the (claimed, but untrustworthy) app id passed into your init(), jsonp out to your domain, then either:
Return a code valid for making API requests with, if the user is logged in* and has already authorized the app.
Pop up a window to your site (or redirect, or whatever) to have the user login (if needed) and authorize the app.
You'll have control of the user experience during authentication, and can do some human verification of the app id (show the claimed logo, name, etc.).
This does assume that you even have a notion of users, like Facebook does.
*Check cookies, not all browsers accept them in response to ajax requests; but all browsers will send them.