Understanding Oauth2/Openid client authentication methods with Redhat SSO

Oauth2/Openid client authentication methods with Redhat SSO : this article explores the Oauth2/openID confidential client authentication methods, and brings some insights using Redhat-SSO example.

1) Public Client, Confidential Client

There are 2 types of clients: public client and confidential clients

  • Public Client:
    Clients incapable of maintaining the confidentiality of their credentials They are also incapable of secure client authentication
  • Confidential client:
    Clients capable of secure client authentication and able to maintain the confidentiality of their credentials

For more details, see RFC 6749 section 2.1

2) Oauth2/openID client access type with RedHat SSO

There 3 possible types of access:

  • public: does not require a secret
  • confidential: client requires a secret to initiate the login protocol
  • bearer-only: client are web services that never initiates a login (example: an application connnecting to a database)

The bearer-only type is special  kind of confidential client with no login, and is for example used for an application to connect to a database.

On the remaining of this article, the focus is brought on confidential clients and bearer-only to perform secure authentication
The client access type has to be at first configured with  « confidential » or « bearer-only ».  Within RedHat SSO, once teh acccess type is configured, another client TAB appears on the top left menu called « credentials ».

Confidential clients also comes with 2 different ways of dealing with:

  • client_id/client_secret
  • signed JWT

In the remaining of this article, the 3 followings aspects are illustrated with keycloak examples:

3) Confidential  – client_id/ client_secret

This illustrated with the example demo/customer-portal. It is based

3.1) RH-SSO configuration for client secret

Client access type: Confidential

RH-SSO client is configured with

3.2) client application -keycloak.json

The client application (customer-portal) is updated using keycloak.json

3.3) web.xml

3.4) standalone.xml

The following has also to be added to Jboss application Server standalone/configuration/standalone.xml

3.5) tracing inner calls

Tracing internally with the SAML tracer firefox plugin, it is possible to follow the openID request

The GET request is issued when  getting the screen where to authentify to

3.6 deciphering ID_token

4) Confidential client – signed jwt

When dealing with client-signed jwt, you have to deal pick USE_JWKS URL selection.

When USE_JWKS is enabled, it means that RH-SSO server will directly read the client application public key (if public key are used) from the customer keystore URL.

When USE_JWKS is disabled, it means that client application  public key has to be directly imported in RH-SSO public key store

Using a client application USE_JWKS enabled keystore allows to easily to rotate customer application keys as there is no need to import new keys within RH-SSO server.  Once client application keys are updated, RH-SSO detects that the client kid  header has changed and will it reimport a new public key.

This is not the case, when USE_JWKS is disabled, You need to update the RH-SSO with the new key of your client application.

4.1) RH-SSO Client configuration
  • Client access type: Confidential
  • Client Authenticator: signed JWT
  • Use_JWKS URL: ON
4.2) client application keycloak.json

4.3) web.xml

4.4) standalone.xml

 

5) Jwt bearer-only

This case implies that there is no login screen, and is used for web services to connect to an application.

5.1) RH-SSO Configuration
  • client access type: bearer only
  • Client authentificator: signed JWT
  • No Client ceertificate configured
5.2) client application – keycloack.json

5.3) web.xml

5.4) standalone/configuration/standalone.xml

5.5) building a signed JWT using java code

In this file, authentication  to the database is done using  JWT bearer Authentication.

It is done in 2 steps:

  • a JWT token is retrieved session.getTokenString()
  • the authorisation bearer tag is added to the header

    The following piece of code illustrates how to get JWT to query the database

5.6) Retrieving the values from a JSP

The Product list is displayed as follows:

6) pointers

RFC 6749  The OAuth 2.0 Authorization Framework
RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC 7515 JSON Web Signature (JWS)
RFC 7516 JSON Web Encryption (JWE)
RFC 7519 JSON Web Token (JWT)
RFC 7523  JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants

Olivier Rivat

Olivier Rivat

Senior Software Engineer with over 25 years of experience doing Software Development, Support and Consulting in Identity and Access Management Solutions.
Specialised in IAM (security, access control, identity management) and Open Source integration, settled in 2004 by IAM industry veteran, JANUA offers high value-added products and services to businesses and governements with a concern for Identity Management and Open Source components.
JANUA provides better security, build relationships, and enable new cloud, mobile, and IoT offerings from any device or connected thing.
Olivier Rivat