Hi Matteo,
Following up from my previous comment in which I mentioned the Device Code OAuth Flow, it turned out an issue sneaked in, but I was able that it has been resolved in PAL 3.1.5.
The requirement is however that you have an OIDC provider in which you can set up an application (type) that supports the 'Device Code' grant type. I'm using Auth0 personally, but I know people, for demo purposes, have been using authentik as well, both of which support 'Device Code' grants, as most modern OIDC providers will. Once set up you'll have Client ID (and Secret) and defined an API identified by an 'audience', the 'audience' you will need to have defined as part of the OIDC configuration in your PA installation!
The client initiates the flow using the the Client-ID of the application and the 'audience' identifying the API that is authentication, as configured in your OIDC provider. Note that asking for `offline_access` in scopes is only required if the client wants to get a refresh token as well (which the client would presumably store safely somewhere if it did). The request (template) will look like:
###
# @name device_code_initiate
POST {{oidc-issuer-uri}}/oauth/device/code
Content-Type: application/json
{
"client_id": "{{client_id}}",
"scope": "openid profile email offline_access",
"audience": "{{audience}}"
}
The response will contain a URL which needs to be presented to the user to allow him to authenticate the request. In my test this response looks something like (might differ slightly depending on the OIDC provider being used):
{
"device_code":"DISBiwQxQ4tBMFrHH85ZtNQE",
"user_code":"BPXS-PPGW",
"verification_uri":"https://excitor.auth0.com/activate",
"expires_in":900,
"interval":5,
"verification_uri_complete":"https://excitor.auth0.com/activate?user_code=BPXS-PPGW"
}
In a browser open the `verification_uri` and fill in the `user_code`. In my case, I use Auth0 as my OIDC provider, I can get there directly but following the complete URI that is provided for convenience as well. This verification process will require you to authenticate first if you don't have an active session going with the OIDC provider already.
Next the client queries the OIDC provider for the token. This request looks like:
###
# @name device_code_token
POST {{oidc-issuer-uri}}/oauth/token
Content-Type: application/json
{
"grant_type": "urn:ietf:params:oauth:grant-type:device_code",
"device_code": "{{device_code_initiate.response.body.device_code}}",
"client_id": "{{client_id}}"
}
If the user hasn't completed the authentication we'll get a 403 Forbidden response with typically accommodated by an "authorization pending" message and it'll have to wait a bit longer and try it again. On success the response contains the `access_token`, an `id_token` and, if `offline_access` was specified in the scope, and enabled for the user/audience, a `refresh_token` will be include as well.
Now that we have the access token we can make a request to Planning Analytics, providing the token as a `Bearer` token in the `Authorization` header of the request (on the first request only, it'll create a session and return a cookie to represent it). For example we can now query the Cubes of one one of the TM1 databases running in PA as in:
###
GET {{pa_root_url}}/api/{{pa_tenant_id}}/v0/tm1/{{database_name}}/api/v1/Cubes
Accept: application/json
Authorization: Bearer {{device_code_token.response.body.access_token}}
If everything worked as expected you'll be looking at a JSON response with the list of Cubes in your TM1 database!
And wrt to that `refresh_token`, keep it for safe keeping, next time instead of requesting a new code to authenticate simply use the refresh token, which typically are long lived and can be configured/secured/revoked in/by your OIDC provider, to get a new access token as in:
### If a refresh token was given that refresh token can, later, be used to request a new access_token
# @name device_code_token
POST https://excitor.auth0.com/oauth/token
Content-Type: application/json
{
"grant_type": "refresh_token",
"client_id": "{{client_id}}",
"refresh_token": "{{device_code_token.response.body.refresh_token}}"
}
Note that in the samples given I'm referring to previous requests based on name. The format of the requests I'm using will allow you to run these from with a .http file in VSCode if you have installed the "REST Client for TM1 Developers" add-in!
Hope this helps you going, have fun!
------------------------------
Hubert Heijkers
STSM, Program Director TM1 Functional Database Technology and OData Evangelist
------------------------------