Technical contributions

OpenID Connect - Web Applications

Reading time

Most web applications require authentication of users and authorization of these users for actions and resources. This authentication and authorization can be implemented with OpenID Connect (successor to OpenID), for example, which is based on the OAuth 2.0 protocol.

What is OpenID Connect?


OpenID Connect is an open and decentralized authentication and authorization system that extends the OAuth 2.0 protocol. Tokens are used to authorize protected resources. A token in OpenID Connect is a JSON object with information. It is Base64 encoded and can be validated. After authentication, the OpenID Connect provider (authentication system) provides an access token to authorize the user, the refresh token. This is required to request a new access token and the ID token for the user information. Because the web application does not require authentication by username and password, the web applications and resources do not have to securely store and manage this sensitive data. Because OpenID Connect is a decentralized authentication system, SSO (single sign-on) is easy to implement. In addition, the access token (possibly also the ID token) provides the REST API interface with all the necessary user information to authorize the user for tasks (REST APIs should always be stateless).

The different types of tokens


The OpenID Connect Provider provides three tokens after successful authentication: access token, refresh token and the ID token. The tokens are not normally encrypted with the standard configuration. They always contain a lifetime and a cryptographic signature. The lifetime and the signature in the token allow the token to be validated locally in the respective resource.

 

The access token is required for authorization and is specified in the header under "Authorization" with the prefix "Bearer " when the resource is called up. The access token normally has a short validity period and must be requested again after expiry.

 

The refresh token can be used to request a new access token from the OpenID Connect provider without the need for further authentication. The refresh token normally has a longer validity period. If the access token and the refresh token have expired, the user must re-authenticate.

 

The ID token contains the user-specific information as key/value pairs. The ID token is also the JWT token (JSON Web Token). The other tokens can also be JWT tokens. An attribute line or a key/value pair with the user information is also called a "claim".

The authentication process


When accessing a protected resource for the first time, the user is redirected to the authentication page of the OpenID Connect provider. After the user has been successfully authenticated, the user is redirected back to the client and receives the three tokens (access token, refresh token and ID token). The client can use the access token to access the protected resources (if the access token does not contain any user information, the ID token must also be provided). The access token is validated in the resource and the required user information is claimed from the JWT token after successful validation. If a protected resource is requested again and the access token is no longer valid, the access token is requested again via the refresh token. If the refresh token has also expired, the user must re-authenticate.

An example scenario for the use of tokens


Given:

 
  • User has a user account with Keycloak and has the necessary rights to view his invoice
  • There is a "Last invoice" button in the web app
  • The REST API for invoices is protected


Scenario:

  1. The user starts the web app and clicks on the "Last invoice" button
  2. The web app validates tokens:
  3. 1. access token is still valid: Continue to 3.

    2nd Access token has expired, but the refresh token is still valid: Web app requests new tokens with the refresh token from Keycloak

    3. no tokens available or expired: The web app redirects to the Keycloak authentication page

  4. The user logs in and is redirected back to the original page
  5. The web app makes a REST call (with access token) to the invoice resource
  6. The resource validates the access token
  7. The resource claimed from the JWT token (in this case from the access token) the customer number
  8. The resource sends the invoice back as a response
  9. The web app displays the invoice

More articles

Webinar

Webinar: More efficient, smarter, faster: how AI agents can help your company move forward

December 12, 2024

11:00 - 11:30 a.m.

Artificial Intelligence | Webinars

Webinar

The asset administration shell as the standard for digital twins

January 15, 2025

11:00 - 12:00 a.m.

Industry 4.0 | Webinars

Webinar

Practical insights: How AI agents strengthen your company

January 14, 2025

10:00 - 10:30 a.m.

Artificial Intelligence | Webinars

Case Studies

SMC: Pioneering Industry 4.0 with digital twins

Industry 4.0 | New business models

Transmission confirmed

Thank you for your interest. Please click here to start your download.

Transmission confirmed

Thank you for your interest. Please click here to start your download.