Skip to main content Skip to complementary content

OpenID Connect for integration with identity providers

OpenID Connect (OIDC) is used for integration of Qlik Cloud with identity providers. OIDC is a thin identity layer on top of the OAuth 2.0 protocol. OAuth 2.0 is the standard protocol for authorization and OIDC the standard protocol for authentication of users. Together, these two protocols enable you to access multiple apps and web sites in a safe way, without having to log in several times, through single sign-on (SSO).

OAuth 2.0 is designed only for authorization. You can grant access to data and features from one application to another, by providing the requesting client with a key. By using a key you do not have to disclose your credentials. Instead, you reuse your credentials with an application where you are already a registered user, for example, an email provider. The key ensures that you only share information that you have agreed to share. You also have the power to withdraw the key whenever you want.

The key is useful but does not give any information about you as a user. OIDC adds functionality around login and profile information about the person who is logged in by using ID tokens. OIDC allows different clients (web based, mobile, Javascript, and others) to verify the identity of the user based on the authentication performed by an authorization server. Clients can also request basic profile information about the user.

For an introduction to OAuth and OpenID Connect, refer to the following video: An Illustrated Guide to OAuth and OpenID Connect.

ID tokens

OpenID Connect uses ID tokens that simplify integration and support a wide variety of apps.

An ID token is a specifically formatted string of characters known as a JSON Web Token or JWT. JWTs are versatile and support a range of signature and encryption algorithms. Clients can extract information embedded in the JWT, such as ID, name, when you logged in, ID token expiration, and if there have been attempts to tamper with the JWT. The pieces of data inside the ID token are called claims.

As mentioned previously, clients use OAuth 2.0 flows to obtain ID tokens, which work with both web apps and native mobile apps.

Access tokens

In addition to ID tokens, there are access tokens: credentials that can be used by an application to access an API. An access token can be a JWT or non-JWT token. The token is used to inform the API that the bearer of this token has been granted access to the API.


JWT Tokens contain claims, which are statements (such as name or email address) about an entity (typically, the user) and additional metadata.

The OIDC specification defines a set of standard claims. The set of standard claims include name, email, gender, birth date, and more. Should you want to collect information about a user which is not covered by a standard claim, you can create custom claims and add them to your tokens.

OpenID Connect specification

The OpenID Connect 1.0 specification consists of the following documents. Qlik supports this specification, not all specific custom vendor implementation of the specification. Qlik may choose to add a convenience configuration for our customers for popular identity management products and platforms.

  • Core: Defines the core OpenID Connect functionality: authentication built on top of OAuth 2.0 and the use of claims to communicate information about the user
  • Discovery (Optional): Defines how clients dynamically discover information about OpenID providers
  • Dynamic Registration (Optional): Defines how clients dynamically register with OpenID providers
  • OAuth 2.0 Multiple Response Types: Defines several specific new OAuth 2.0 response types
  • OAuth 2.0 Form Post Response Mode (Optional): Defines how to return OAuth 2.0 Authorization Response parameters (including OpenID Connect Authentication Response parameters) using HTML form values that are auto-submitted by the User Agent using HTTP POST
  • Session Management (Optional): Defines how to manage OpenID Connect sessions, including postMessage-based logout and RP-initiated logout functionality
  • Front-Channel Logout (Optional): Defines a front-channel logout mechanism that does not use an OP iframe on RP pages
  • Back-Channel Logout (Optional): Defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out
  • OpenID Connect Federation (Optional): Defines how sets of OPs and RPs can establish trust by utilizing a Federation Operator

To access the documents, go to Welcome to OpenID Connect.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!