I am trying to do a login like Google does, which includes a cross-domain-authentication. When loggin into google.com you are automaticly logged in for different domains like youtube.com. For me it looks like:
you enter credentials at accounts.google.com
Google sends a request via AJAX to check them
if they are correct, it 1. sets a cookie and 2. does requests to the other domains like youtube and sends some identifiers (SID or token?) and sets the cookies for those domains as well
after all other domains also have the cookie in place Google redirects you back where you came from
I was researching a lot and it seems like easyXDM (http://easyxdm.net/wp/) is a good solution for this (do you think it is?). But I am not sure how to do the cross-domain-authentication. When the user logs in correctly, should i just do requests to the other domains and pass the SID and create cookie on the domains? Or is it not secure? Or should I create a token for the user after loggin in and store it in my DB. Then send the token with to all the domains to authenticate him and then delete the token?
Some other stuff i found was a solution via iframes in iframes.. also Googles analytics.js (https://developers.google.com/analytics/devguides/collection/analyticsjs/cross-domain) looked exciting... but i saw it's even integreated in easyXDM.
I hope some if you guys are having experience with that stuff. I am curious to read what you think :) gerti
What you want is OAuth2 (this is the protocol you're referring to -- what Google login does).
If you're looking for a simple solution, you might want to try using something like Stormpath + IDsite. It's a free API service you can sign up for / use.
Basically, they'll host a domain for you where you redirect your users when you want them to create an account or log in. They'll then handle all the authentication / authorization (across domains), and send you back an authenticated user with a JSON web token (JWT).
Stormpath has a bunch of libraries for a variety of programming languages, you can get started here: https://docs.stormpath.com/home/
The other solutions people typically go with require quite a bit of time / effort to get running. I've actually helped build quite a few of the Stormpath libraries (in Node / Python), so I'm pretty familiar with it -- you really can't beat it in terms of simplicity.
Related
I'm planning to refactor a legacy Rails 2 app by splitting the logic into a RESTful API, and the view into a separate Javascript client. The API itself will be protected by oAuth2. This is basically the second option explained on this question:
Separate REST JSON API server and client?
There's a lot of questions out there concerning the security of using oAuth with a JS app, the main concern seems to be that storing the access token on the client is a bad idea since it acts as a password and someone that has physical access to the computer can hijack the user's identity. A possible solution I've read is to expire the access token every 1h or so and use the refresh token stored on Yahoo's YQL to request a new token when necessary. This doesn't looks to me like a good solution since at the end you'll need again a token to access the YQL service.
But at the end, aren't we facing the same problem as when using persistent sessions? I mean, AFAIK, the common method to keep the session alive across browser opening/closing (when you tick "remember me") is to generate a token associated to a user and store it both on the DB and on a long-living cookie. So again, anyone with access to this cookie has the "key" to your session. AFAIK this is the method all the "big guys" use.
I am right? And if I am, aren't we worrying too much about something that we cannot control at all? Of course I'm talking about those applications where an intrusion is not too harmful for the user like social networks, blogs, forums, etc.
I need a primer web/javascript security.
According to How to use an HTML/JavaScript client for Windows Azure Mobile Services, in javascript on the client side, after including a link to MobileServices.Web-1.0.0.min.js you're supposed to create a client like this:
var MobileServiceClient = WindowsAzure.MobileServiceClient;
var client = new MobileServiceClient('AppUrl', 'AppKey');
which means including my AppKey in the javascript on the page. Should I be worried about the AppKey being public?
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in. The usefulness of this is somewhat reduced with a cross-origin resource sharing whitelist, but what's to stop someone with this information from adding javascript to the page and executing arbitrary operations on my backend database? Restricting table permissions to authenticated users wouldn't help in this scenario.
Do I need to be concerned? What do banking apps do about this sort of thing?
In the same link which you shared, application key is defined as a not safe mechanism to authenticate users - A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
More over when you enable some authentication on all the endpoints either using ACS or through Open Authentication, if you main ASP.Net/PHP etc page got authorized, then browser is going to handle federation of identity through cookies for next on-going calls till your session ends.
In most of the applications having HTTPS would protect from Man in middle attacks. Also strong encryption logic on cookies along with very specific expiry times would increase the bar of security. Also IP address based checks would definitely help in improving security.
ramiramilu's answer covers most of the question. There's one more thing which I'll add:
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in
Yes, someone can add a breakpoint and find out the value of the X-ZUMO-AUTH header which they're sending. But the value of that header is specific for the logged in user (in this case it would be the "attacker" [him/her]self) - it wouldn't be able to get information from other people out of that header. And there are even easier ways to get the value of that header (just browse to https://<mobileservicename>.azure-mobile.net/login/<authProvider> and after entering your credentials you'll see the header encoded in the URI).
I want to create a web widget that will display information from my site.
The widget will be included in the client's website HTML using JavaScript, and should only be usable for my clients -- web sites that were registered at my site.
The information in the widget should be specific to the user who is currently visiting the client's site.
So, I need to authenticate both the client (website owner) and the resource owner (website visitor). This seems to map nicely to OAuth 2.0, but I couldn't find a complete example or explanation for such an implementation.
Any resources or pointers to such information will be appreciated.
Update: I've stumbled upon this article, which provides an outline for an approach that uses OAuth. However, it is not detailed enough for me to really understand how to use this with OAuth 2.
There are many large organizations that have done this, and I'm sad to see no other answers for this question since it's such an important web pattern.
I'm going to presume that you are not rolling your own OAuth 2.0 provider from scratch, if you are - well done otherwise you should be using something kickass like Doorkeeper to do this for you.
Now, in OAuth 2.0 you have the following entities:
Users registered on your website
Applications registered on your website (who subscribe to your oauth2)
User Permissions which is a list of Applications that a user has 'allowed'
Developer (who is consuming your auth API / widgets and building an Application)
The first thing to note is you must have a domain name associated with each Application. So if a developer registers for a API token / secret on your website, the Application he creates is mapped to a unique domain.
Now, I presume that the flow for an application to authenticate users via your website is already clear. That being said, you don't need to do much for this to work.
When an Application sends the user to your website (in order to sign in) you place a session cookie on the user's computer. Lets call this "Cookie-X".
Now the user is authenticated by your website and goes back to the Application. There we want to show a custom widget with information pertaining to that user.
The developer will be need to copy paste some code into this app.
The flow is like this:
The code will contain a url to your website with his Application ID (not secret) which he got when registering his application on your website.
When that code runs, it will ping your website with his appId. You need to check that AppID with your database, and additionally check that the referrer url is from the same domain as that which is registered in your website for that AppID. Edit: Alternatively or additionally, the code can check for document.domain and include it in the ping to your website, allowing you to verify that the request has come from the domain that has registered with the given AppID.
If that is correct, you reply back with some JS code.
Your JS code looks for the session cookie your website had set when the user had signed in. If that cookie is found, it pings back to your website with the session and your website responds with the custom view content.
Edit: as rightfully mentioned in a comment, the cookie should be HttpOnly to safeguard against common XSS attacks.
Additional Notes
The reasons this is a secure approach:
The AppId and domain name are a good enough combination to verify that other people are not fetching this information. Even thou the appId is visible in the applications html source, the domain name would have to be spoofed by anyone attempting to use someone else's AppID.
Presuming someone takes an AppID which is not his, and writes code to spoof the domain name of the referrer when requesting for your widget, he still won't be able to see any information. Since you are showing user specific information, the widget will only render if your website can find the session cookie it placed on the users browser which can't really be spoofed. There are ways around like session-hijacking, etc. But I think that's beyond the scope of this question.
Other Methods
Just by looking at Facebook's Social Plugins, you can tell that there are other options.
For example, one might be to use an Iframe. If you ask the developer to add an Iframe to his application, you can even reduce a few of the steps mentioned above. But you will have to add JS along with it (outside the iframe) to grab the correct domain, etc. And ofcourse from an accessibility and interface standpoint I'm not very found of Iframes.
I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?
I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.
I am developing an iGoogle Gadget. I have to access the spreadsheet data of logged in user. How do I implement an OAuth for it?
You have to become an OAuth Consumer of the Google services - they are the OAuth provider in your case.
There are a lot of open source implementations of the protocol in various languages, but I would suggest to read through the RFC if you want to implement it - it's clearly written and not very long.
The official site has good reads and links too:
http://oauth.net/
Basically it's a protocol that exchanges a little bit of data between you (your application aka the consumer), the provider and your user with internal HTTP requests between you and the provider (exchanging tokens) and some redirects through the user's browser between you and the provider again.
Also, you as a consumer will have to store some tokens and data regarding these interactions. It's not very complicated and in the same time is very interesting thing to implement. I learned things about security, request signing, some http details and headers. And if you already know these things, then you will do it a lot faster than I did :)
OAuth is just an API that Google gives out to developers to let them authenticate Google accounts in other manners other than just going on google.com - for example through a programmatic way.
Authentication is the basis of it, but through OAuth you're able to retrieve lots of information from a specific Google account (calendar info, contacts etc.)
To implement this you would need to read more on their website:
https://developers.google.com/identity/protocols/OAuth2