Qlik Sense: How to request an OIDC token manually and check if correct attributes are included (PowerShell)

[Damien_V]

This article explains how to request a token manually from your Identity provider token endpoint and verify if the required attributes are included in the id_token.

Qlik Sense Enterprise for Windows reads the attributes from the id_token and is not using the /userinfo endpoint to fetch them.

Environments:

Qlik Sense Enterprise on Windows  May 2021 and higher
Qlik Cloud (For "ADFS" and "Azure" Identity provider types only)

First of all, for testing purposes, add the URL "https://test/login/callback" used in this script in your Identity Provider (IdP) allowed redirect URIs. The reason we are doing this is because we want to request the token manually to check its content and not have it getting automatically processed by Qlik Sense.

1. Run the below PowerShell script to get your authorization URL. Variables authorization_endpoint, client_id, and scope need to be updated to match your IdP, those information can be found from the /.well-known/openid-configuration endpoint.
   

   $authorization_endpoint = 'https://dc1.domain.local/adfs/oauth2/authorize'
   $client_id = '592a5672-a360-49da-93a4-20654f42d3c2'
   $redirect_uri = [System.Web.HTTPUtility]::UrlEncode("https://test/login/callback")
   #For ADFS, use 'openid%20allatclaims%20profile%20email' for the scope
   $scope = 'openid%20profile%20email'
   $code_challenge="7TsROgPKuP0hHoWWwEGqMsIOgzokT3xAz8kWoo7Ivp8"
   
   #Paste this URL in your browser to get back the authorization code
   $authorization_endpoint+'?response_type=code&client_id='+$client_id+'&redirect_uri='+$redirect_uri+'&state=xyzABC123&nonce=3O2bsVV99-kjikCWCxqzxOx007aXbKMUd0YXBwA3sUk&scope='+$scope+'&code_challenge_method=S256&code_challenge='+$code_challenge

2. Paste the URL output from the script in your browser and log in to your Identity provider, the URL should look like this:
   

   https://dc1.domain.local/adfs/oauth2/authorize?response_type=code&client_id=592a5672-a360-49da-93a4-20654f42d3c2&redirect_uri=https%3a%
   2f%2ftest%2flogin%2fcallback&state=xyzABC123
   &scope=openid%20allatclaims%20profile%20email​

   
   After the authentication is completed, you will be redirected to https://test/login/callback with an authorization code in the URL, copy the authorization code that we will use in the next step.
   
   Copy the value between code= and the next & sign. (The length of the authorization code may vary depending on the IdP)
   
   
   
   
3.  Request the token from the token_endpoint URL (also found from the /.well-known/openid-configuration endpoint)
   

   $client_id = '592a5672-a360-49da-93a4-20654f42d3c2'
   $redirect_uri = [System.Web.HTTPUtility]::UrlEncode("https://test/login/callback")
   $client_secret = 'Ssxx92jvm6RE_Plf1NnKgduZujE99nd0vWuujE_L'
   $token_endpoint = 'https://dc1.domain.local/adfs/oauth2/token'
   $code_verifier="_fqY.Xg5srawq24h9_A57tjY-ycqX0PzzIcM7VcwLZRou_Mvqn-_tCTz4ICWcXoCTO8NXlm3b9RfGOjSZEH68a_gWgaLByddN5y52M06~Z8XlO3XMgOJRWK0DefsxcmC"
   
   #Put your authorization code here
   $auth_code = 'mSzqI71WMUGuYcxSTciAcw.kZdiCG6J2QgNAPRcEZ9A51OMW6g.TMrNMhHPBiG3aNbh_4lbUakFzWoU_MFcDQZcL6_wBIaDd_1_DMWz9OZUSvRcE_zR115HwNXdZYUTjHB6mcnK3u5R2EDxsVKthwQwbP184ujVK1c8LmI-QOMb4jEGRTAm49nbtM8MfO4pTO1fICMSU7CLuhVb8KcCefjPOQ5W0JMKLl7XElvhJDLg5n6v1V2m8L2ZaCQVDy6oTiZygIr20j3TpQnpu2Zwk1KzbttOTGqeJgzCoyPJJJcRjnOrD1zPmBEENrz8fuZwdihRIPZufzhj0gEJ18-stWBz7polztBH7y_jKn-mK6WgIqlLSG2AlmcQa9kBANLmfbal7OUFtA'
   $pair = "$($client_id):$($client_secret)"
   $encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
   $basicAuthValue = "Basic $encodedCreds"
   
   $hdrs = @{}
   $hdrs.Add("Authorization",$basicAuthValue)
   $body = 'code='+$auth_code+'&grant_type=authorization_code&redirect_uri='+$redirect_uri+'&code_verifier='+$code_verifier
   
   $response = Invoke-WebRequest -Uri $token_endpoint -Method Post -Body $body -Headers $hdrs -ContentType 'application/x-www-form-urlencoded'
   echo $response.Content​

4. Copy the value in "id_token" from the request response, and decode the JWT token to see what it contains.
   
   For simplicity, you can use the debugger on https://jwt.io :
   
   
   
   You can confirm if the expected claims are included in the token payload or not.

[rockabs]

@morenoju Sorry, Quite occupied. Yes, Realm should be linked to your domain otherwise the configuration is not able to understand how that is recognized. And, I've requested already @Damien_V to update the document on the help page, I guess he and his colleagues are working.

[austin1]

@Damien_V When setting this up to get the authorization code, the url that it takes me to gives me this 

I have set up the redirect url just fine. 
A couple of things that I had to do differently.
1. the /.well-known/openid-configuration didnt have any of the things you mentioned that should be there. So I tried getting the client_id by using keycloaks api (https://www.keycloak.org/docs-api/15.0/rest-api/index.html#_clients_resource) and the id that looked similar to yours didnt work it said client id not found. So I put in just the name of the client id and that brought me to the login page but then after logging in it gave me that screenshot above.
2. Since the scopes werent there either, I used that same api to get the defaultClientScopes and the optionalClientScopes and used those in every combination I could come up with. It seemed to not effect the outcome.
3. The authorization endpoint seemed to be working, it just looks a bit different than the one you have. It ends in auth instead of authorize.

Let me know if there is anything that im missing!

[Damien_V]

Hello @austin1 

It is expected that you get "The site can't be reached" since we're using a dummy URL to avoid that the authorization code gets processed (since it would be invalidated once processed)

You can just ignore the error and proceed to the next steps.

[rbpeterson2]

Anyone have a screenshot of what their settings are when it works?  Here's what I currently have based on what I see coming back from the powershell token response(s):

{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/{azure-tenant-guid}/",
"iat": 1701112528,
"nbf": 1701112528,
"exp": 1701117041,
"acct": 0,
"acr": "1",
"aio": "AVQAq/8VAAAAmpwPIrk8L08ZhuENI8IW3bRaz4a1UcsgHqr7xHkYP6Z69oj+EvC5wyuQUcHJmNsL/skckDuh2XF2pPgHSlRyJRTEHfq2YhAmCBLY3dtTHvY=",
"amr": [
"pwd",
"mfa"
],
"app_displayname": "ApplicationDisplayName",
"appid": "{applicationId}",
"appidacr": "1",
"family_name": "Peterson",
"given_name": "Rob",
"idtyp": "user",
"ipaddr": "20.25.66.160",
"name": "Rob Peterson",
"oid": "e6908031-3180-4546-bdca-b9c6788babf9",
"platf": "3",
"puid": "10032002EB5AF179",
"rh": "0.AXcAjGmYFdLLSk2U8AtLK3AXYwMAAAAAAAAAwAAAAAAAAAB3AMo.",
"scp": "User.Read.All profile openid email",
"sub": "ChTR8smDV6O5sQG9aTTZ79rGdLxqdpzcG-StE7aFbV4",
"tenant_region_scope": "NA",
"tid": "{azure-tenant-id}",
"unique_name": "rob.peterson@companydomain.com",
"upn": "rob.peterson@companydomain.com",
"uti": "CMjcvDDDJ0Coe3lAHpOPAg",
"ver": "1.0",
"wids": [
"b79fbf4d-3ef9-4689-8143-76b194e85509"
],
"xms_st": {
"sub": "Amr9I4-LW0pKufRa7zwsSOhS9Wpx3QzUlvNTz_DcEiI"
},
"xms_tcdt": 1426775194
}

[rbpeterson2]

@rockabs @Damien_V  can you post a response from the token data from jwt.io and a screenshot of the configuration for the virtual proxy when it works please?

[Sonja_Bauernfeind]

Hello @rbpeterson2 

An example of the token data can be seen in the last screenshot attached:

As for an example on a virtual proxy configured to work with OIDC, see Qlik Sense for Windows: How to configure OIDC with Keycloak.

If you need additional guidance, please post your query directly in our Qlik Sense Integrations forum. Alternatively, if you are looking for direct assistance with an ongoing implementation and customization, contact our Professional Services.

All the best,
Sonja 

[roelvandeven]

Hi all,

We have setup Qlik Sense Enterprise on Windows to use Azure AD with OPENID.
All working well, except that we get the groupid instead of the group names for users.

I assume it has something to do with the Azure settings, but can't seem to find the anser.

Hopefully one of you can help me.

Kind regards,

Roel

[rbpeterson2]

@roelvandeven - this is based on the level of product subscription of Azure.  The lower tiers only provide the GUIDs whereas the higher tiers provide the GUIDs and names.  At least that is what we have found when adding multiple clients with different levels of Azure subscriptions in our SaaS product.

[roelvandeven]

@rbpeterson2 - Thank you for your input. The strange thing is, that on our Qlik Cloud tenant I do get the group names. But the setup of the IDP is different of course compared to On-prem.

Any idea on that?