You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the Power BI connector for Trino supports OAuth 2.0 authentication, but it requires users to provide both the client ID and client secret for the connection. However, many environments that use SSO for OAuth 2.0 (such as enterprise setups) do not expose the client secret to end-users. Instead, users authenticate via a web-based SSO flow, as commonly seen with tools like DBeaver, which opens a browser window for authentication without needing a client ID/secret configuration.
The text was updated successfully, but these errors were encountered:
This is a very good point, but alas I don't have the capacity to look into at the moment. I suspect someone with better knowledge of OAuth/SSO could make short work of it. One further point: In the current setup, whereby one populates the files oauth_config_client_id.txt etc. and then builds the .mez file, one can unzip the .mez file and see the values of said files in plaintext. That's not good.
Currently, the Power BI connector for Trino supports OAuth 2.0 authentication, but it requires users to provide both the client ID and client secret for the connection. However, many environments that use SSO for OAuth 2.0 (such as enterprise setups) do not expose the client secret to end-users. Instead, users authenticate via a web-based SSO flow, as commonly seen with tools like DBeaver, which opens a browser window for authentication without needing a client ID/secret configuration.
The text was updated successfully, but these errors were encountered: