Forum Discussion
Power Query custom connector with combined authentication types
- 11 months ago
Hi jnickell , Thank you for reaching out to the Microsoft Community Forum.
Extension.CurrentCredential() can only return one credential record at a time, even though VS Code shows both UsernamePassword and Key stored. The connector runtime won’t merge them, so you can’t directly retrieve both Password and Key from the same call. That’s why your current approach fails. Greg_Deckler was right that you could hardcode the API key, but that weakens security. vojtechsima correctly said, you should either stick with Dataflows (where credentials are already protected in the service and hidden from end users) or move to Fabric Notebooks/Pipelines with Key Vault for stronger enterprise security.
If you do want to continue with a connector, the usual pattern is to define a single authentication kind and pass the API key as a required parameter that you inject into the request header. That way you avoid mixing credential types, which isn’t supported. You weren’t wrong in thinking about connectors, but you’re not as exposed as you feared with Dataflows, they already give you a decent security boundary.
vojtechsima could you comment on my previous reply to tell me if I'm off base in my conclusion?
Hi jnickell , Thank you for reaching out to the Microsoft Community Forum.
Extension.CurrentCredential() can only return one credential record at a time, even though VS Code shows both UsernamePassword and Key stored. The connector runtime won’t merge them, so you can’t directly retrieve both Password and Key from the same call. That’s why your current approach fails. Greg_Deckler was right that you could hardcode the API key, but that weakens security. vojtechsima correctly said, you should either stick with Dataflows (where credentials are already protected in the service and hidden from end users) or move to Fabric Notebooks/Pipelines with Key Vault for stronger enterprise security.
If you do want to continue with a connector, the usual pattern is to define a single authentication kind and pass the API key as a required parameter that you inject into the request header. That way you avoid mixing credential types, which isn’t supported. You weren’t wrong in thinking about connectors, but you’re not as exposed as you feared with Dataflows, they already give you a decent security boundary.