Introduction

OpenId Connect (OIDC) is an identity layer built on top of the OAuth2 protocol.

When the user authentication is required the client application initiates one of OIDC Core flows and redirects this user to OIDC provider. The user gets redirected back to the client after the authentication, with the client application receiving IdToken. If Authorization Code Flow is used then IdToken is returned as part of the follow up code to access token exchange, and if Implicit Flow is used then IdToken is returned immediately.  It is very much like OAuth2 except that an extra IdToken parameter is returned.

CXF ships OIDC Provider (IDP) and Relying Party (RP) utility code to make it easy for developers to create their own custom OIDC providers or have JAX-RS applications integrated with well-known 3rd party OIDC IDPs.

This code relies heavily on CXF OAuth2 and CXF JOSE modules.

Maven Dependencies

CXF OIDC module
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-rs-security-sso-oidc</artifactId>
    <version>3.1.7</version>
</dependency>

IdToken and UserInfo

IdToken is a primary extension that OIDC makes to OAuth2. It provides a collection of claims describing the authenticated user. IdToken is a secured JWT token which is JWS-signed and/or JWE-encrypted by OIDC IDP.

CXF provides org.apache.cxf.rs.security.oidc.common.IdToken.

One way to populate it is to register a custom SubjectCreator with either OidcAuthorizationCodeService or OidcImplicitService. For example, Fediz OIDC uses the following SubjectCreator: it accesses a user principal prepared by Fediz Authenticators and creates IdToken by converting an already available SAML token to IdToken and sets it on OidcUserSubject. In other cases a user principal may already have a prepared IdToken. 

The other approach is to create IdToken in a custom OAuthDataProvider at the moment a code grant or access token is persisted. In this case IdToken will need to be populated first and then converted to either JWS or JWE sequence and saved as a grant or token "id_token" property: if it is a code flow then set it as a grant property at the moment the grant is persisted, if it is the implicit flow - set it as a token property at the moment the token is persisted. This approach is a bit more involved but creating a JWS or JWS IdToken representations with CXF JOSE is straightforward.   

In general the way IdToken is created is container/implementation specific. Creating IdToken is the main requirement for integrating CXF OIDC code with the 3rd party container.

Finally, IdTokenResponseFilter (used by AccessTokenService to complete the authorization code flow) or OidcImplicitService can ask IdTokenProvider to create IdToken at the moment it needs to be returned to the client application. 

IdToken can provide enough information for the client application to work with the current user. However, the client can get more information about the user from OIDC UserInfo endpoint.

CXF provides  org.apache.cxf.rs.security.oidc.common.UserInfo. One can create and set it at OidcUserSubject at the same time IdToken is created or let CXF OIDCUserInfo service create it as described below.

OIDC IDP support

Currently CXF OIDC IDP code provides JAX-RS services for supporting OIDC Authorization Code, Implicit and Hybrid flows. These services support all OIDC response types.

Services for supporting UserInfo requests and returning IdToken signature verification keys are also shipped. 

OIDC Flow Services

Authorization Code Flow

OidcAuthorizationCodeService is a simple AuthorizationCodeGrantService extension which enforces OIDC specific constraints. 

This service issues a code grant, while AccessTokenService returns Access and Id tokens. 

IdTokenResponseFilter (used by AccessTokenService) is where IdToken is actually added to the client response.

Implicit Flow

OidcImplicitService is a simple ImplicitGrantService extension which enforces OIDC specific constraints and adds IdToken to the client response. In order to return an id_token, the OidcImplicitService should be configured as follows:

  1. If the response_type is "id_token token", then the IdTokenResponseFilter should be configured on the OidcImplicitService. The IdTokenResponseFilter in turn needs to know how to create an IdToken, so it must be configured with a IdTokenProvider implementation.
  2. If the response_type is "id_token", then a IdTokenProvider implementation should be configured directly on the OidcImplicitService.

Hybrid Flow

OidcHybridService supports Hybrid Flow by delegating to both OidcImplicitService and OidcAuthorizationCodeService.

UserInfo Endpoint

UserInfoService returns UserInfo. It checks UserInfoProvider first, next - OidcUserSubject, and finally it defaults to converting the existing IdToken to UserInfo.

Note UserInfoService is accessed by a client which uses the access token issued to it during the user authentication process.

JWK Keys Service

OidcKeysService returns a JWK key set containing a public verification JWK key. By default only a public key is returned but the service can also be configured for JWK key to include the corresponding  X509 certificate chain too.  Use this service if IdToken is signed by a private RSA or EC key for the client be able to fetch the verification keys without having to import them into local key stores. The OidcKeysService can also return a public key stored in a JWK keys file, by specifying the id of the key via "rs.security.keystore.alias" and specifying the type of the keystore ("rs.security.keystore.type") as "jwk".

OidcDynamicRegistrationService

This service is available starting from CXF 3.1.8. It supports the dynamic client registration and management with OIDC specific properties being handled too. At the moment some of the advanced registration properties are not yet processed and linked to the way the core OIDC services operate but the service will be enhanced as needed going forward.

OidcConfigurationService

This service is available starting from CXF 3.1.8. It supports OIDC server configuration queries at ".well-known/openid-configuration".

Fediz OIDC IDP

Fediz OIDC project provides a reference integration between CXF OIDC IDP code and Fediz Authentication System. It has OIDC Core supported with a minimum amount of code and configuration.

It creates IdToken in a custom SubjectCreator as described above. Currently it depends on CXF Ehcache OAuthDataProvider OOB so no custom persistence code is needed. Besides that it provides a support for managing the client registrations. It registers OIDC services as JAX-RS endpoints.

While some implementation details may change going forward (example, the alternative data provider may get introduced, etc), for the most part it shows that creating IdToken is what is really needed to get the container integrated with the CXF OIDC code.

OIDC RP support

OIDC RP client support is needed for the client application to redirect a user to OIDC IDP, get and validate IdToken, optionally get UserInfo, and make both IdToken and UserInfo easily accessible to the client application code.

Demos

BigQuery demo service is OAuth2 client which relies on CXF OIDC RP code to support interacting with the user, redirecting the user to Google to authenticate, and validating IdToken returned from Google AccessTokenService alongside a new access token (OIDC Authorization Code Flow). The demo service uses IdToken to address the user correctly and the access token to access the user's resources as authorized by the user.

For example, the context is injected and used to get the access token and the user info. See the context with the comments on how to configure RP filters.

BasicOidc demo service is not an OAuth2 client, but a basic JAX-RS server. This server works with an HTTP Browser client which uses Google script libraries to get IdToken from Google OIDC Authorization endpoint (OIDC Implicit flow). This browser client interacts with CXF OIDC RP code to get IdToken validated and then posts this token to the demo service. Demo service depends on CXF OIDC RP to have this IdToken easily accessible in its code