There are several industry standard methodologies to provide single sign capability. Due to the level of integration required, creating a customized solution would be cost prohibitive and would lack the credibility in terms of security and standardization that all of the following solutions have.
Open ID
OpenID is an open, decentralized standard for authenticating users which can be used for access control, allowing users to log on to different services with the same digital identity where these services trust the authentication body. OpenID replaces the common login process that uses a login-name and a password, by allowing a user to log in once and gain access to the resources of multiple software systems.
An OpenID is in the form of a unique URL, and is authenticated by the user's 'OpenID provider' (that is, the entity hosting their OpenID URL). The OpenID protocol does not rely on a central authority to authenticate a user's identity. Since neither the OpenID protocol nor Web sites requiring identification may mandate a specific type of authentication, non-standard forms of authentication can be used, such as smart cards, biometrics, or ordinary passwords.
OpenID authentication is now used and provided by several large websites. Providers include AOL, BBC, Google, IBM, Microsoft, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!.
Logging in
The user visits a relying party web site (e.g. website.relying.com) which displays an OpenID login form somewhere on their page. Unlike a typical login form with fields for the user name and password, the OpenID login form has only one field—for the OpenID identifier, typically along with a small OpenID logo: Openid small logo.png. This form is connected to an implementation of an OpenID client library.
A user typically will have previously registered an OpenID identifier (e.g. alice.openid.provider.org) with an OpenID identity provider (e.g. openid.provider.org). The user types his OpenID identifier into the aforementioned OpenID login form.
The relying party web site typically transforms the OpenID identifier into a canonical URL form (e.g. http://alice.openid.provider.org/). With OpenID 1.0, the relying party then requests the web page located at that URL and reads an HTML link tag to discover the identity provider service URL (e.g. http://openid.provider.org/openid-auth.php). The relying party also discovers whether to use a delegated identity (see below). With OpenID 2.0, the client discovers the identity provider service URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.
SlashID
Unlike OpenID, SlashID operates closer to a password and profile manager. SlashID keeps up with information such as the user's email address, website, and contact information, and sends that information to the requesting website when the user inputs their SlashID username and password.
Both systems require the website to support the feature before it can be used, and this is their main obstacle in achieving universal acceptance.
The Benefits and Downside of SlashID
The major benefit of SlashID over OpenID is its ability to keep track of more information, which makes it more adaptable to websites. A user can even have multiple profiles, so if they want to use one email on some websites, and a second email on other websites, this can be easily accomplished.
The biggest downside of SlashID is its current dependence on a single website. While OpenID allows almost anyone with their own website to set up an OpenID server, SlashID is run from a centralized source. There are plans to decentralize the authentication process, but this will be dependent upon SlashID gaining some acceptance across the web.
Implementation
Both of the above methodologies for granting authenticated access are similar. In both cases the third party sites must install and configure the authentication libraries. Security changes to the third party sites must include the implementation of the library on the front end.
Additionally, the company would have to control the token ID's that are permitted authentication.
