/ /

Masked credential fields for integrations and App Tile configurations

Updated 23 days ago

Overview

To reduce the risk of accidental exposure and align with security best practices, passwords and other sensitive credentials are now masked by default across integration setup and App Tile configuration experiences. This protects secrets during entry, testing, and edits, while keeping admin workflows straightforward.

Who this is for: Admins, App managers, and Integration managers working with integrations, custom connectors, API actions, and App Tile configuration flows.

What’s changed at a glance

Simpplr now applies a consistent “secure input” pattern anywhere credentials are entered:

  • Sensitive fields are masked by default (shown as ••••••).

  • A Show/Hide (eye) toggle lets you temporarily reveal values while entering or updating them.

  • After saving, values remain masked and are never revealed automatically.

  • When editing, previously saved values are retained if you leave the field unchanged.

Where you’ll see masking

Masking applies wherever the platform collects secrets, including:

  • Custom app connection setup (connector authentication flows).

  • API action configurations (App Tile Builder, workflow or API task setup).

  • Endpoint testing dialogs (Test connection or Test action).

  • OAuth and token configuration screens (Client Secret, access or refresh tokens, and similar).

  • Any modal or inline form that captures credentials or other secrets.

Which fields are masked

The following field types are treated as sensitive and are masked:

  • Passwords.

  • API keys.

  • Access tokens and refresh tokens.

  • Client secrets.

  • Authentication secrets and similar sensitive values.

Note: Client IDs may appear unmasked where appropriate. Client Secrets and tokens are always masked.

How it works

  1. Default state is masked: Sensitive inputs show ••••••.

  2. Reveal only when needed: Select the eye icon to temporarily show what you’re typing or verifying.

  3. Always masked after save: Saved secrets never display in plaintext, not even later on the same screen.

  4. Safe edits: When editing an existing configuration, the rules below apply.

  • The masked field indicates a value exists.

  • If you don’t change the field, the previous value is preserved.

  • If you type a new value, it overwrites the stored credential.

Common scenarios

Create a new connection

  • Enter credentials in masked fields.

  • Use Show briefly if you need to confirm what you typed.

  • Save to store credentials securely; the UI remains masked.

Edit an existing connection

  • You’ll see a masked placeholder indicating a stored credential exists.

  • Leave the field untouched to keep the current value.

  • Enter a new value to replace it.

Test an endpoint or action

  • Test dialogs follow the same masking behavior.

  • Test results never echo secrets back into the UI.

Accessibility and usability

  • The Show/Hide toggle is keyboard accessible.

  • The toggle uses clear ARIA labels (for example, “Show secret value” or “Hide secret value”).

  • No value is lost when switching between masked and unmasked states.

  • Consistent behavior across desktop and supported mobile browsers.

Security and privacy principles

  • Least exposure: Secrets are never displayed in plaintext after save.

  • No accidental leakage: Secrets aren’t surfaced in typical UI or network logs during standard operations.

  • Secure by default: Matches common admin tool patterns and security expectations.

Best practices for admins

  • Use Show only when necessary (especially avoid during screen sharing).

  • When rotating credentials, overwrite the field with the new secret.

  • Prefer OAuth over static secrets when available.

  • Rotate long-lived tokens on a schedule.

Some notes

  • UI masking reduces casual exposure, but doesn’t replace security fundamentals like rotation, scoped access, and backend encryption.

  • Exported configurations and logs do not include plaintext secrets.

Troubleshooting

Identify your issue below, understand what happened, and take the right action.

You can’t see the old value when editing a credential field

  • What happened: This is expected behavior. Saved secrets are never auto-revealed in the UI.

  • What to do: If you leave the field unchanged, the existing value remains in place. You don’t need to re-enter it to keep the current credential.

Test connection fails after editing a configuration

  • What happened: You may have accidentally typed into a masked credential field, which overwrote the stored secret with whatever you entered.

  • What to do: If you didn’t intend to change a secret, confirm you didn’t overwrite the masked field. Re-enter the correct value and test again.

The Show/Hide toggle doesn’t reveal the value

  • What happened: Browser password manager or autofill behavior can sometimes interfere with the Show/Hide toggle.

  • What to do: Check your browser’s password manager and autofill settings. Then focus the field, re-enter the value, and toggle again.

FAQs

Q: Can I copy a saved secret from the UI later?

Ans: No. After save, secrets are never auto-revealed. To update, overwrite with a new value.

Q: Are secrets masked in API responses or exports?

Ans: Yes. Secrets are redacted; plaintext values are not returned in UI-bound responses or exported configuration files.

Q: Does this apply to OAuth flows?

Ans: Yes. Any UI field that captures sensitive values (Client Secret, tokens, and similar) is masked. Redirect-based OAuth steps don’t display tokens in the UI.

Q: Is the visibility toggle accessible?

Ans: Yes. It’s keyboard accessible, updates ARIA attributes, and preserves typed values across states.

Was this article helpful?
Subscribe to receive updates on this article