OpenID authentication overview
OpenID is an open standard that enables users to authenticate themselves to multiple entities without managing multiple accounts or sets of credentials. WebSphere Application Server supports OpenID 2.0, and plays a role as a Relying Party (RP) in web single-sign-on.
Terminology
- OpenID Identifier:
- An http or https URL or an Extensible Resource Identifier (XRI) that belongs to an OpenID Provider or a user.
- OpenID Provider (OP):
- An OpenID Authentication server that can verify whether a user controls a unique identifier.
- Relying Party (RP):
- An entity that requires proof that a user controls a unique identifier.
To access 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 users are required to sign in to an entity (a website, for example) that supports OpenID and acts as a Relying Party, users authenticate by interacting directly with an OpenID provider rather than providing their credentials to the RP. An OpenID provider verifies the identity of the user and sends an authentication confirmation back to the RP. When this confirmation is received from the OpenID provider, the RP accepts the user as authenticated. A typical OpenID authentication flow is shown as in the following graphic.
Figure 1. A typical OpenID authentication flow
The graphic lists the following typical OpenID authentication flow:
- The user attempts to access protected resource (a web page, for example).
- The RP (WebSphere Application Server, in this example) presents a form login page for the protected
resource.
- The user enters an OpenID Identifier.
- The RP takes the user Identifier and redirects the user to the appropriate OpenID provider.
- The OpenID provider prompts the user for credentials.
- The user enters credentials for an account that is associated
with the OpenID provider.
- The OpenID provider authenticates the user, and optionally prompts
the user to approve or deny providing user information to the RP.
It then redirects the user back to RP with the authentication result.
If the OpenID provider authentication was successful, RP attempts to authorize the user. If authorization succeeds, RP establishes an authenticated session with the user.
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. No website other than the OpenID Provider ever sees the user's credentials. OpenID reduces the possibility of an unscrupulous or insecure website compromising a user's identity. The user also controls how much personal information is shared with the websites that the user visits. For example, users might choose to allow the name and email address that is 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:
Avoid trouble:
The OpenID 2.0 Claimed Identifier should be used to identify a user, per specification. However, the Claimed Identifier is not user friendly and many Relying Parties choose one of OpenID attributes to represent user. The most popular attribute used to represent user is user's email address. For more information about identifying a user, see Identifying the End User section of the OpenID Authentication 2.0 documentation
It is known that some OpenID attributes, including email, might not well validated by OpenID provider. If we do not trust or know that a provider will provide you a verified email address, you must not use the provider's email as the authenticated user name in WebSphere Application Server. gotcha
Related concepts
Related tasks