Sign-In for Outside Services

Some outside services do not take a plain key. They want a key file that is traded for a short lived access token, or a person to sign in once and approve. A custom connection can use either one, for any service. The examples here use a made-up service at example.com; a real one works the same way with its own addresses.

This page is confidential: only owners and admins see connections, and AI agents never do.

The Two Styles

• Service Account Key. You paste the key file the service gave you (a JSON file with a client_email and a private_key), the address the service gives out access tokens at, and the scopes to ask for. MountDev Ops seals the whole file in your workspace. When a call is made, it signs a short request with the private key and trades it at the token address for an access token, then sends the call with that token.
• One-Time Sign-In. You enter the client id and client secret from your own account with the service, the service's sign-in address, its token address, and the scopes. You select Sign In, approve at the service once, and the service sends you back. MountDev Ops trades the code it gets for a lasting sign-in (a refresh token) and seals it at once. When a call is made, it trades that for a fresh access token.

Neither style is tied to one service. The addresses are yours to enter: for example, a service that lives at api.example.com might give out tokens at https://auth.example.com/token and ask people to sign in at https://login.example.com/authorize.

What Is Saved and What Is Never Kept

• The key file, the client secret, and the lasting sign-in are sealed with your company's own key, and never shown again.
• The signed request and every access token are never saved. An access token is held in memory only, reused until a minute before it ends, and asked for again after that.
• A token, a secret, or a key is never put in a workflow run, the Activity Log, an error message, or a list.
• The scopes, the token address, and (for a one-time sign-in) the client id and sign-in address are not secret. They are shown on the connection.

Scopes

Scopes say what the connection may do at the service, such as read:items. Enter up to 20, separated by spaces or commas. For a one-time sign-in, Sign In shows the scopes in plain words before you go to the service, and the service's own page shows them again. After you approve, the connection shows the scopes the service says it allowed. Changing the scopes, the client id, the client secret, or any address of a one-time sign-in ends the sign-in, so you sign in again and approve the new scopes. Changing only the name or purpose keeps it.

Adding and Signing In

Actions (owners, admins, and anyone whose role allows changing setup; never AI agents or API keys):

• core.connections.save adds or changes the connection with the sign-in style service_account or oauth, with the details token_address, scopes, and for a one-time sign-in client_id and authorize_address, and the key file (secret) or the client secret (signing_secret).
• core.connections.signin.start starts a one-time sign-in. It answers the service's sign-in address and the scopes, and keeps a one-time value that works once, for 15 minutes.
• core.connections.signin.finish is called by the workspace when the service sends the person back to the return address (/account/connection/callback). It works only for the person and company that started the sign-in, only once, and only within 15 minutes. The return window says what happened and never shows a code or a token.
• core.connections.check (Check Now) proves the sign-in. With a check address it also makes one GET with the access token. Without one it only proves the trade.

Changing how a connection signs in needs its own new key. The old key is never reused as another kind of secret.

When Something Is Wrong

• A service that ended the sign-in, or a refresh the service no longer accepts: the connection shows Failing with "The service ended this sign-in. Select Sign In to do it again."
• A one-time sign-in that was never finished: "This connection has not been signed in yet. Select Sign In."
• A key file the service does not accept: "The service did not accept the service account key (400). Check that the key is still active and the scopes are allowed." The service's own wording is never repeated.
• A token address that is not https, is on a private network, or does not resolve to a public address is refused when it is saved and again at every trade.

Using It in a Workflow

The Call a Web Service step calls these connections like any other custom connection (action core.web_call). The sign-in happens inside the step. The access token never appears in the step, the run log, or an error. A service that sends a new lasting sign-in with a refresh has it kept in place of the old one in the same call.

Choosing the Style on the Screen Planned

The Add a Connection pop up does not offer the two styles yet. The actions above work now; the screen waits for its design to be approved.