The authentication approach of the Bosch.IO Service Dashboard follows open principles. The intention is not to provide a new identity store. The focus lies on integrating existing Identity Providers and offering several login mechanisms to our customers. Using the OpenID Connect standard, authentication mechanisms supported by existing Identity Providers are supported Bosch.IO Service Dashboard (e.g. user name / password). A list of currently supported Identity Providers can be found below. After the authentication process a JWT Token is available that includes all relevant information.
The diagram below illustrates the interaction of the Bosch.IO Service Dashboard with an external Identity Provider.
The Bosch.IO Service Dashboard supports the following Identity Providers:
- Azure AD
- Bosch ADFS
- Bosch Single Key Id
Besides that, the Bosch.IO Service Dashboard provides an own custom identity store if none of the existing IdPs fits to the customers' requirements.
Via OpenId Connect or other standard protocols additional Identity Providers can be integrated based on customer requests.
There are several tokens that are generated during the authentication flow.
ID tokens (https://auth0.com/docs/tokens/id-tokens) are used during token-based authentication to cache user profile information and provide it to a client application, thereby providing better performance and experience. The application receives an ID token after a user successfully authenticates, consumes the ID token and extracts user information that can be used to personalize the user's experience.
ID tokens should never be used to obtain direct access to APIs or to make authorization decisions.
Access tokens are used during token-based authentication to allow an application to access an API. The application receives an access token after a user successfully authenticates and authorizes access. Afterwards, it passes the access token as a credential when it calls the target API. The passed token informs the API that the bearer of the token has been authorized to access the API. Actions performed are specified by the scope that was granted during authorization.
Auth0 issues an access token or an ID token in response to an authentication request. You can use access tokens to make authenticated calls to a secured API, while the ID token contains user profile attributes represented in form of claims. Both are JSON web tokens (JWTs) and therefore have expiration dates indicated using the exp claim, as well as security measures, such as signatures. Typically, a user needs a new access token when gaining access to a resource for the first time, or after the previous access token granted expires.
A refresh token is a special kind of token used to obtain a renewed access token. You can request new access tokens until the refresh token is on the DenyList. Applications must store refresh tokens securely because they essentially allow a user to remain authenticated.
In order to ensure a friction-less user experience, digital services provided via the Bosch.IO Service Dashboard can be accessed via Single-Sign-On (SSO). The validation of users that want to access specific services and data is done via Keycloak. Based on the JWT Token described above, the Bosch.IO Service Dashboard is trusted by an external application and directly logs the user into this specific application (Single Sign On, SSO). The Bosch.IO Service Dashboard supports the following approaches:
- Based on a JWT Token (Id, access and refresh token)
- Session cookies
- Technical user (not a real SSO)
The following sections describe and illustrate the different approaches.
Using this approach, the Service Provider grants access to the digital service by validating the JWT Token (Access token) with the Keycloak of the Bosch.IO Service Dashboard.
Using this approach, the Service Provider grants access to the digital service by sending the session cookie to the Keycloak of the Bosch.IO Service Dashboard. If the session is valid, the request will be redirected to the application.
If the session is not valid, the request will be forwarded to the login page. After re-login the request will be redirect to the application.
To use this approach, the Service Provider needs to offer an REST API to request an JWT Token based on exactly one technical user. After the authentication of this technical user (by validating and accepting the created token), the user is able to access the external service.
A guide on how to connect your application to the Keycloak of the Bosch.IO Service Dashboard can be found here: Connecting applications