Janrain has been a great influence in the OpenID community and I thank them for all their efforts. They are, nevertheless, a company that must generate profits, and their recent invention of RPXNow is one attempt at doing that. It generates revenue for them: check. But is it really in your web site’s best interest to use RPXNow instead of using OpenID directly? I don’t think so.
I have not used RPXNow myself, for reasons I will describe. So what I will discuss is from my reading the documentation about their service and seeing how it works from an end user’s point of view.
Confusing to users
When users login, their OpenID Provider will usually tell them that they’re logging into yoursite.RPXNow.com instead of www.yoursite.com. Even if your visitors are willing to go ahead and login in spite of this oddity, you are teaching your users to get phished by disregarding what ought to be a warning message to them.
RPXNow allows you to customize this “realm” URL that is displayed, but doing so requires more work on your part, and costs more per month for the service. And RPXNow was all about making it easy, so doing the extra work to get the right realm displayed to your users is something of a step backward for their primary selling point, I’d say.
Less stability
RPXNow.com introduces an intermediary between your site and the OpenID Provider. One of the criticisms of OpenID already is that your users won’t be able to log into your site if their Provider is down or cancels their account. Adding RPXNow between your web site and the Provider adds yet another possible point of failure for your users. It is worse, in fact, because users may have multiple Providers so they can still log in if one goes down; but if you use RPXNow and RPXNow goes down, they are helpless and you won’t see any logins at all.
OpenID has also been criticized because logins can take a bit longer due to the 1-2 hops between your server and the OpenID Provider to complete authentication. This may be a moot point, but it can only get worse when you add yet another third party in the authentication protocol.
Less security flexibility
Your site may need to make its own decisions about which Providers it is willing to accept OpenID logins from. Or it may need to control the policies that should apply when dealing with those Providers. Since RPXNow completes these steps for you, you lose out in your ability to customize the process to the same extent you could if you were using OpenID directly at your site.
Proprietary protocol
OpenID was designed exactly to allow your sites to accept logins from many other OpenID Providers. Doing this right and securely is in fact a big job, but there are numerous free and open source libraries that have done this heavy-lifting for you and you just need to hook up to it.
RPXNow’s sales pitch is that they handle the complexities of the OpenID protocol for you. But to get that you have to talk to them in their proprietary protocol. They give you a library for that so that it’s “easy”, but what have you gained from this? Without RPXNow, you need an OpenID library and to hook it up to your site. With RPXNow, you need their RPXNow library and to hook it up to your site. The frontends to either library that you will have to interface with turns out to be very similar. So it’s not significantly easier to hook up RPXNow than it is OpenID itself (assuming you picked a decent OpenID library).
There is one advantage to RPXNow abstracting OpenID away from you that I can think of however. It is their job to stay on top of patching their implementation of the OpenID protocol and keeping you secure instead of yours. For a big company, that actually is more of a risk than a benefit. But for many web sites, this is an advantage because otherwise they may get OpenID ‘working’ and then consider it done, and ignore all the security updates and new OpenID versions that may come out that may put their users at risk.
Vendor lock-in
Janrain claims to make it easy for you to stop using their RPXNow service if your needs change. But they do not volunteer the complications that may be involved in parting ways.
Remember how the realm is often ‘yoursite.rpxnow.com’? Much worse than simply confusing users, it can end up locking users out of their accounts. Google, and others to follow, choose to use a feature of OpenID that allows them to protect their users from collaborating relying parties so that their usage on the Internet cannot be tied together. But the way this is done is using that same realm URL. If your realm URL ever changes, all your users who log in using their Google OpenIDs will have to create new accounts with your site and will no longer be able to log into their old ones! This would be very upsetting to your customers, and you would get emails/calls in about this from every one of your loyal Google customers.
Let’s say you start with yoursite.rpxnow.com and decide to switch to the more costly option of sticking with RPXNow but using your own domain name for the realm, or just switching off of RPXNow altogether. Either way, you’re screwing over your Google customers (and potentially other OpenID Providers that choose to follow Google’s example). The only way to use RPXNow without this eventual end result is to pay the money to RPXNow to use just your own domain name at the start. But again, that’s more work and more money. And if you just accept OpenID yourself directly you can avoid the more money, and avoid the other issues we’ve discussed at the same time.
Alternatives to the benefits they offer
RPXNow does make logging in easier for your users than the typical OpenID text box. With some work on your end, you can achieve a similarly easy UI for your users on your own. Or better, the OpenID libraries that you can use directly can have this functionality built-in so that it’s still just as easy, and yet you’re hosting it all yourself.
RPXNow also offers user login and account creation statistics. But this too can be achieved relatively easily using other means like Google Analytics, which is a free service.
Summary
Since RPXNow introduces several problems, web developers should avoid it for now in favor of an OpenID library. Janrain would do well to repackage RPXNow as a product that can be purchased instead of a service in order to avoid most/all of the issues I list above.
Andrew, I love you, but let me challenge your assertions.
1) site.rpxnow.com. This is the trust root for our free basic service only. For $20/month a site can their own trust root. The cost really isn’t that much more than the SSL cert and the labor to configure it. We have not had one single feedback that this trustroot confuses end-users.
2) Stability. You are correct there is an extra hop in the process, but it’s a completely automatic redirect, no user interaction, there isn’t much of a chance for this to fail or add noticeable latency. What does make RPX a great solution is it adds a higher availability authentication engine than most sites could do themselves. Because we are putting substantial engineering resources into RPX, and doing authentication at scale there are dozen of cases where RPX performs where most native implementations would fall down. Paying customers get an SLA.
3) Security/Pick of Providers. Both the free and paying customers get a best practices implementation. All data always moves over SSL. For free customers we provide a widget that allows one click access to the major Providers. Paying customers can chose their own providers, as well as whitelist/blacklist.
4) Proprietary Protocol. Andrew you are missing the point here. There is no library, it’s an HTTPS call and then a JSON or XML response. It is *way* simpler to OpenID enable your site with RPX, than using a library. Most of our customers don’t want to learn OpenID, they don’t want to have to fiddle with installing libraries and dependencies, they don’t want to have to change their database schema, they don’t want to have to worry about security holes, and most of all they don’t want to have to maintain and scale this authentication going forward. You can spend man years learning OpenID, AX, SREG, hCard, OAUTH, Facebook, or you can use RPX and be operational in an afternoon.
5) Vendor Lock In. No Way. As a company we have taken great pain to make RPX completely open and free from any kind of lock in (unlike some players in this field). We don’t do anything to obscure or lock up any of the customers data. They are free to quickly move to a native implementation or another vendor. In fact we have many customers who are using RPX as a pilot and have or intend to go native. A customer of RPX has ownership of all their data. Google identifiers are a challenge. For customers upgrading their trust root, we assist in using the verified email address from google as an key. This works nearly perfect. Google and JanRain are working on an additional solution that should be out in Febuary.
Andrew, I think you forget that you are a black belt in OpenID, and that most of the site operators are not. In summary, I’ll repeat: You can spend man years learning OpenID, AX, SREG, hCard, OAUTH, Facebook, or you can use RPX and be operational in an afternoon. There is a free offering, and a commercial offering if you want an SLA, support, and some extra features.
larry-
I am about to deploy a site using RPXNow. I was quickly able to allow users to use their google, yahoo, aol or openid account without much code on my end, BRILLIANT!! I do see your points but I feel the ease of use and functionality outweighs them. I for one hope they stick around.
Thanks for your comments, Larry. I definitely want this post to be accurate and I appreciate your clarifying and correction remarks. Here are some extra thoughts to the individual points you made:
1) Point taken. As I said in my post, a customized trust root is an additional cost. $20/month is a good price for what you’re offering though, true enough. As far as confusing the users though, I’ve heard confusion/complaints about it. On the general OpenID mailing list itself when openid.net started using RPXNow, people were wondering why rpxnow.com appeared during login. I was confused myself before I knew what RPXNow was. If OpenID were clearly understood by everyone, everyone who is not already familiar with RPXNow should be confused when they see the strange trust root. So that tells me it’s a bad idea to use rpxnow.com as the trust root, even for your free service. If I as a user think I’m logging into foo.com, and I see that I’m logging into foo.rpxnow.com, even if I knew what rpxnow was all about, I could legitimately be concerned that I was not being misled, as foo.rpxnow.com isn’t necessarily the same people who run foo.com.
2) Great response.
3) Ah! Being able to whitelist/blacklist was something I did not know you offered to paying customers. That’s great. I would take exception to your “all data always moves over SSL” comment. As long as I can login with my http://blog.nerdbank.net/ OpenID, then there’s data traveling without SSL as part of authentication. If, for my site, that HTTP traffic was unacceptable, do you have a story for that? (that’s just a question… not a challenge)
4) My apologies. I thought I saw a library for RPXNow, but perhaps it was just the class that you offer others to drop into their web site, or someone else’s library that’s built to make it so that that source code is not even necessary. That being said, I personally find using DotNetOpenId easier than the protocol and source code that I read about at RPXNow.com. This post wasn’t meant to be an ad for any particular OpenID library, but just as an example of why I was saying what I said, with DotNetOpenId, you copy a file (the .dll) and drop in a control on the login page (drag-n-drop), and you’ve got OpenID support. I can replace a username/password login on a web site in five minutes using DNOI, plus however long it would take to adjust the database to use Claimed Identifiers instead of username/password. But the database change, and any extra features beyond that I imagine would be the same between DNOI and RPXNow.com because it’s site-specific work. I say in my post though, that once it is set up, a web master should still be watching for security updates to come out for whatever OpenID library he/she chooses – whereas I see that with RPXNow since the code on the site is so simple, there’s very little chance of a need for the webmaster to do any further work as any security patches would be Janrain’s responsibility. I agree, this is definitely a value-add for some web sites to use RPXNow.
5) Please don’t take my comments as an accusation that you’re trying to lock people in. I appreciated your web page that describes how you try to avoid locking your customers in, and I think that’s awesome! It’s definitely way better than Windows Live ID (aka MS Passport)’s primary ID # that is Microsoft specific (as I understand it… although I’ve never used their service either). I am just really concerned about the account splintering problem. I’m very pleased to hear that you’re working on a solution with Google for that though, and I’m eager to learn more in February when the details are revealed.
I realize that web sites are not in business for their login page. Web masters want to get done with the login page as quickly as possible so they can go about building what makes their site unique and interesting. I definitely see the need to keep OpenID as simple as possible for the average web visitor as well as the web developer. The must be OpenID libraries to make this possible. The RPXNow service has a niche where web developers can benefit, and Janrain has done a slam dunk job at making the login experience user-friendly. Way to go! I hope everyone has OpenID login pages as easy as yours. Your SaaS approach is good for web programmers that want to write their login page and forget it. For those of us interested in reducing their web site’s dependencies however in exchange for watching for updates ourselves, I hope you also offer it as a self-hosting product, with an upgrade subscription plan, perhaps.
Andrew, after spending three days learning about the complexities of OpenID, it was a no-brainer to delegate the task to rpxnow.
Maybe it's because I'm tired of reinventing the wheel, but you wont' see me again trying to get OpenID libraries to work correctly with all providers 😐
Yeah, the whole complexities of OpenID right now force developers to seek for simpler solutions. And I think wpxnow is only first one to commercialize on this complexities. More will come if whoever is responsible for OpenID as protocol won't do something to make it easier dramtically.
Hi Andrew,
We do agree with your comments and believed that an open source library that you can incorporate in your code to do all authentication will be useful. So we have come up with socialauth – http://code.google.com/p/socialauth
Will appreciate any of your comments and anything we can do to make things better for the community.
Warm regards,
Abhinav
Chief Technical Officer
BrickRed Technologies
I just found this post as one of the first responses on a Google search for "rpxnow".
I was very concerned when I first saw the domain when logging in to a new service, as it reminded me a lot of certain weight loss drugs! Fortunately, this site did at least clear up that misconception, but I do think that encouraging users to accept a service with such an easily misconstrued name is a bad policy!
Regards,
Nick
wow, this is quite old blog, but just wanted to add that there is better service LoginRadius (www.loginradius.com) available now which does have these issues!! I personally like it and using it on my site.
And 4.5 years later I find this via Google search to figure out why the heck I'm getting an "rpxnow" trustroot on a site with a completely different domain name. So thanks!
I have one simple question. If the government ever stepped in and said 'Give us your database and shut-up.'.. would you hand it over, or delete the database and apologize to your customers.
I suppose you could move it off-shore.. but yeah, let's just try to answer that one simple question.
'RPXNow' is terribly slow. Its benefits are moot if my users can't login.
Andrew,
your post is still 'giving' thanks for your contibution.