It's clear there there is no consistent set of features among any of the popular authentication providers.

Below is an attempt to aggregate the similarities and differences I've noticed, but I would appreciate your advice on what additional features that are missing, and what are the important features to consider when looking at an outsourced provider.


  • 2 Factor Authentication Per Session (Google, Verisign , MyOpenID)
    • Blackberry, Android, iPhone, application (Verisign, Google)
    • Text (MyOpenID , Google )
    • Voice (MyOpenID via PhoneFactor, Google)
    • Browser Certificates, and Physical Token (Verisign)
  • 2 Factor Authentication Per computer: Facebook
  • Beta (features subject to change) Yahoo 2/22/13
  • Force Password Change (LiveID every 72 days)


  • Email Address Hidden/Not Shared (LiveID, ClickPass)
  • Offers a unique ID per website (ClickPass )
  • Information Sharing Controls (Yahoo, Facebook, Google, LiveID, LiveIDServices)

Forgot Password Feature

  • Most Secure (Google has Phone, OTP, and a difficult survey to fill out)

Delegation Support

  • Verisign
  • ClickPass
  • (many others)

SignIn Seal / SiteKey

View Authentication History

  • Full Logging of date, action, and target MyOpenID
  • Good logging but inefficient for auditing access Facebook
  • Limited to Grant and remove authentication Google, Yahoo

Active Session Summary

End user features

Supports Connected Accounts

Token Replay Protection

Connection Security


Did I miss any important application features?
Are there some features I shouldn't pay attention to when comparing providers?

Some examples of additional information that is missing in this list include encryption specifics, ISO/SAS70 certification, or if the providers are using DNSSec. I could use help in gathering this information, and prioritizing what's important and not.

Please share additional info, or correct mistakes as you see fit.

  • Beyond features and reputation there may be risk management and governance aspects to consider. Do you have compliance requirements? Is the provider in scope? Does the IDaaS (Identity as a Service) provider have up to date audits (ISO27002, SSAE16 SOC Type II, PCI, etc.)? Do those audits address employee access to authentication systems (signing/encryption keys, usernames, password hashes, system trust relationships) or other sensitive data? Jun 29, 2015 at 20:53

2 Answers 2


The right answer will clearly depend on your application.

For example, you've listed:

Option for "difficult" sign in process to improve security (Verisign), also see this related question

Using a provider like this would be a terrible choice for a site with low login security requirements and a strong desire for low barriers to entry in order to gain user base -- say a stackexchange or twitter. On the other hand it would be a benefit to a site that needs to perform financial transactions.

To some extent it will also depend on the combination of your users' preferences combined with the reputation of the provider. If you force users to use, say, Facebook, in order to sign up then you may lose users who have shunned Facebook. Or google -- they already have enough data about me, why would I want them to know every time I log in to your, say, dating site?

Lastly, I think one "feature" you are missing is the history of actual (versus promised) security. If a given provider has had a series of failures, it's likely they will continue to have failures. This is not to say that a provider with no known vulnerabilities will not have some exposed in the future.


A key issue when using an outsourced identity provider (IdP) is a position of trust. Do you trust them? The trust factor will take many forms and it is imperative that you walk your business sponsors through the advantages and disadvantages of federated trust models before going for it.

  1. Do you have an explicit or implied contract with the IdP? This is important because if your business relies on a third party IdP then you must ensure that the commercials are fully understood about what you can and can't do with the trusted identities and whether the IdP can pull the service without notice etc.
  2. You don't say whether the users are the general public or staff. If they are staff then you must consider the JML (joiners, leavers, movers) process and ensure that you have the associated processes in place to manage who is authorised to view what. Federation neatly solves a lot of the authentication - but none of the privileges and authorisation.
  3. You have listed some great federated mechanisms that are useful in public websites. If you are also federating with staff users (i.e. with your own identities) then you may need a SAML connector. You mention ADFS; which has had it's limitations in the past in terms of SAMLv2 compliance but is great if you use Active Directory as your IdP tool. The industry has a few major players such as Shibboleth (OSS) and Ping with their "Federate" tool. They also have a Ping Connect solution that's a bit cheaper. However, these are only needed if you are the IdP and using a third party service provider (SP). Ping, IBM and CA have federation tools but are at the more expensive end of the spectrum.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .