Skip to main content
Closed

Support for OIDC client credentials in Power BI Connector

Related products:Authentication and Access ManagementOther
  • October 31, 2023
  • 3 replies
  • 69 views
M
Committed

It seems that the Cognite Power BI connector only allows end-user credentials to be used, ever since moving away from API keys. This results in tying headless processes like nightly refreshes of PBI datasets, to the end-user account of the person who developed the reports, which then break when the end user moves on and their account is deactivated. Often this happens when Cognite consultants move from project to project.

Other applications of OIDC e.g. the Cognite SDK, allow for client credentials to be used for this kind of use case. I am therefore wondering why this is not the case with the Cognite Power BI connector?

Our workaround for this use case has always been to use an end user account in AAD which is not set up with MFA, is not required to change password and so on. Our IT department is becoming understandably resistant to this. It would be better if explicit support for OIDC client creds (i.e. an app registration and client id/secret) were in place, then we would not have to do this. 

Would be keen to know if this is something on your roadmap, or whether there were technical reasons it couldn’t be done this way.

3 replies

T
Seasoned Practitioner
Forum|alt.badge.img

Hi, and thanks for reaching out!

Other applications of OIDC e.g. the Cognite SDK, allow for client credentials to be used for this kind of use case. I am therefore wondering why this is not the case with the Cognite Power BI connector?

 

After registering an app in your IdP and obtaining a token by supplying the clientId and clientSecret as part of an OIDC authentication process - could use Python, Power Shell (dunno if this helps?), even a *nix shell script (if you're feeling brave enough to play with curl and pipes!). 

AFAICT, you can then configure your OData feed for CDF to use an Authorization: Bearer <token> header as the authentication mechanism, instead of the standard login with username/password and any MFA. 

By no means authoritative on my part, but hopefully useful?

M
Committed
  • Malcolm Lea
  • Author
  • Committed
  • November 1, 2023

Thanks for the response. It’s food for thought: I didn’t realise about the OData approach to make a direct call instead of using the connector. However, I’m not seeing how we would avoid obtaining the tokens manually before making the OData call, unless PowerBI could also run this part (and store the client secrets and tokens somewhere secure?). If not, any token we used would i) be visible in the query code, and ii) expire after a short period and need to be recreated. 
We’re talking about published reports here which are typically refreshing datasets on a schedule i.e. with no end user present.

It would be great to see authentication via client credentials as part of the PBI connector at some point - any plans to do this?

Elka Sierra
MVP
Forum|alt.badge.img

Hi Malcolm,

Thank you for sharing your idea and contributing to our product development process.

After careful consideration, we’ve decided not to move forward with this suggestion at this time.

Status: Won’t Do
Reason: The feature is not currently aligned with our strategic priorities.

That said, we truly value your input, and if priorities shift or new insights emerge, we’ll be happy to revisit this decision in the future.

Thank you again for your contribution and for helping us improve. If you have other ideas or feedback, we’d be happy to hear them!

Best regards,
Elka

 

Terms & ConditionsCookie SettingsAccessibility statement