Repository navigation
client-id/serviceprincipal id incorrectly masked #566
Description
This makes logs a bit more difficult and confusing to read.
login/src/common/LoginConfig.ts
Line 66 in bbcc074
login/src/common/LoginConfig.ts
Line 45 in bbcc074
Usually I would expect client-ids to be public information, but this action treats them as a secret.
If there is a reason, perhaps that needs to be documented?
Activity
YanaXu commentedon Jan 19, 2026
Hi bt701,
Thank you for your question.
Indeed, some users consider the client ID to be public information; however, many others view it as private. These users are primarily from enterprise environments, where the team responsible for configuring the resources required by the login action is different from the team that actually uses the token after login. Since these teams have different permission scopes for resource management, they do not want the client ID to be treated as public information and passed through to all repository users, as this could introduce certain security risks.
It is also worth noting that secrets in GitHub Actions are not necessarily fully secure. Any workflow with read access is technically capable of retrieving their values and printing them. We classify them as secrets primarily to prevent users from accidentally logging their values, which could otherwise cause issues—especially when the GitHub Action is used in a public repository.
We hope this explanation addresses your concerns.
bt701 commentedon Jan 19, 2026
Hey Yan Xu (@YanaXu) thanks for the reply.
It's good doc to have this represented in the issue so I do appreciate it.
Any organization that views a public piece of data as sensitive is terrifying, and likely have a fundamental misunderstanding of basic security, so hopefully they look at this issue and mend their ways :)
As is, it does violate the principal of least surprise. As I discovered it from other log lines, as GitHub actions marks the occurrence of the secret globally. However at least there is now some documentation that it is a conscious decision.
I'd still vote to remove it, but I truly appreciate your response.
Docs uplift (#620)
gdt-waiariki-koia commentedon Aug 25, 2026
Adding to this, it would be useful if there was a way to disable it. This could be enabled by default to facilitate those concerns you have but a flag to disable this would be handy.
MaddyMicrosoft commentedon Aug 25, 2026
This has been documented #620
As the initial request was addressed, I am going to close this issue off.
bt701 gdt-waiariki-koia I want to avoid this issue drifting and getting lost. If still strongly prefer a feature be added to disable/ toggle this, could you please open a fresh issue with a description of the use case and the workflow that is being impacted/ blocked?
That will help allow us to assess it fully and prioritise appropriately.