Application Passwords for Native Client Authentication with OpenID Connect

Edit online

A new type of authentication flow is provided for native clients to connect to Engineering Lifecycle Management applications that are configured for OpenID Connect authentication (by using a Jazz Authorization Server, or JAS). This flow allows native clients to work with configurations that use certain third-party identity providers for user authentication without directly supporting the protocol that is used by that identity provider.

OpenID Connect (OIDC) is a form of delegated authentication. Instead of handling authentication directly, an application obtains an access token from an OIDC provider (OP) on behalf of a user. The application then uses that access token to represent the identity of the user. The access token can be passed from application to application, providing a single sign-on experience.

The OIDC specification defines various flows for getting an access token, depending upon the type of client used or the application topology. All flows require the user to prove their identity by using some form of credentials, and the OIDC specification does not define the possibilities. Implementations can decide what to support. Most commonly, a username and password is validated against a user registry (for example, LDAP), but implementations are free to support anything they prefer. Other possibilities include smart cards or client certificates, or another type of identity provider such as SAML, Kerberos, or even another OIDC OP.

Because web browsers are commonly used as clients, most identity providers work with them, and count on the client to display web pages and forms, and run JavaScript. Since native (non-browser) clients generally cannot interpret HTML and run JavaScript, it is often more difficult to support browser-centric authentication schemes. The Liberty application password feature is a way to avoid that difficulty by using a web browser to handle an identity provider's authentication scheme. Thus, producing a relatively long-lived token that can then be used by the native client in a simpler protocol that does not depend on the client that is a web browser.

Note: When a Jazz Authorization Server is configured to delegate authentication to something else, then logout no longer works. A logout request from a client is sent to the JAS, but it is not forwarded in any way to the external identity provider that the user really logged in to. So. that login session is not invalidated, and the user is effectively still logged in. Users must decide to make this tradeoff when they decide to use delegated OIDC authentication.