OpenID is an open standard where users can authenticate themselves to multiple entities without the need to manage multiple accounts or sets of credentials. Liberty supports OpenID 2.0 and plays a role as a Relying Party in web single-sign-on.

OpenID Provider (OP)
An OpenID Authentication server that can assert whether a user controls a unique identifier.
Relying Party (RP)
An entity that requires proof that a user controls a unique identifier.
OpenID Identifier:
An http or https URL that belongs to an OpenID provider or a user.

Accessing various entities such as websites often requires a unique account that is associated with each entity. OpenID enables a single set of credentials that are handled by an OpenID Provider to grant access to any number of entities that support OpenID.

When required to sign in to an entity, such as a website that supports OpenID and acts as a Relying Party, users perform authentication by interacting directly with an OP rather than providing their credentials to the RP itself. An OP verifies the identity of the user and sends an authentication confirmation back to the RP. When this confirmation is received from the OP, the RP accepts the user as authenticated.

A typical OpenID authentication flow is described as follows:

  1. A user attempts to access a protected resource, such as a web page.
  2. The Liberty server, acting as a RP, presents a form login page for the protected resource.
  3. The user enters an OpenID identifier.
  4. The RP takes the identifier and redirects the user to the appropriate OP.
  5. The OP prompts the user for credentials.
  6. The user enters credentials for the account that is associated with the OP.
  7. The OP authenticates the user and optionally prompts the user to approve or deny providing user information to the RP, and subsequently redirects the user back to the RP with the authentication result.
  8. If the OP authentication is successful, the RP attempts to authorize the user.
  9. If the user authorization is successful, the RP establishes an authenticated session with the user.
The OpenID authentication flow can be seen here

OpenID helps minimize the chances of user credentials or sensitive information being mishandled. With OpenID, a user's credentials are only exchanged with the OpenID Provider, meaning no website other than the OP ever sees the user's credentials. This standard helps mitigate the possibility of an unscrupulous or insecure website compromising the identity of a user. The user also controls how much personal information is shared with the websites visited. For example, users can choose to allow the name and email address that are associated with their OpenID account to be shared with one website while electing not to provide their email address, or any information at all, to another website.

The OpenID standard specifications that are supported include:

OpenID Authentication 2.0.

OpenID Attribute Exchange 1.0.

Note: The OpenID 2.0 Claimed Identifier must be used to identify a user per spec, Identifying the end user. However, the Claimed Identifier is not user friendly and many Relying Parties choose one of the OpenID attributes to represent the user. The most popular attribute used to represent the user is a user's email address.

It is known that some OpenID attributes, including email, might not be validated by the OpenID provider. If you do not trust that a provider will provide you a verified email address, then you must not use the provider's email as the authenticated user name in the WebSphere Application Server.