Shared vs Per-User Credentials

By default, a connector uses one shared credential for the whole team: the credential an Owner or Administrator saves on the Connectors page. Where that credential is an organization API key or service account, every team member's tool calls go to the vendor through that one identity — which means, in the vendor's own audit logs, everything looks like the same service account did it.

Where the connection was made by signing in rather than by pasting a key, the stored credential carries one person's own access, and the rules are different. Read Who can use which identity below before you assume a shared connection covers your whole team.

Five connectors support per-user credentials, where each team member connects with their own vendor identity:

Who can use which identity

Four rules decide whose vendor identity a tool call runs under. They are enforced on every request, not at setup time.

1. An organization API key or service credential is shared. Where the stored credential is a key, a token or an application credential your organization created, every member's calls use it. That is the intended design, and the vendor's audit trail names the integration rather than a person.
2. A sign-in credential is not a team fallback. Where the connection was made by signing in — HaloPSA or NinjaOne in OAuth mode, and Microsoft Azure or Microsoft Graph, whose credential is always a person's own consent — the stored credential carries the authorizing person's own permissions. StackJack will not run another member's calls under it. A member without their own connection for one of these connectors gets a refusal that names their own fix: personal_sign_in_required.
3. Effective owners keep the fallback. A member whose role is Owner — the primary owner and any co-owner — can still use the shared sign-in credential, so every tool an owner can see stays executable before they personally authorize. Administrators are not owners for this rule: they need their own personal sign-in on these connectors, the same as any other member.
4. Some connectors have no personal remedy. Reddit Ads is authorized once for the whole organization and has no per-member sign-in. A non-owner member refused on Reddit Ads cannot fix it themselves — an owner has to run those tools, or the member has to be made an owner. Their card reads Owner Sign-in Only rather than offering a Connect button.

Microsoft browser sign-in is therefore not a matter of preference for a non-owner. It is the only way that member gets an Azure or Microsoft Graph identity at all: the Microsoft pair uses StackJack's own registered application, so there is nothing for an owner to configure on their behalf and no shared identity for them to inherit.

For what a member sees on each card, see Your personal connector sign-ins.

Why per-user credentials matter

• Real audit trails in the vendor. Ticket updates, device actions, and every other change show up in HaloPSA, NinjaOne, Microsoft Azure, Microsoft Graph or N-central under the actual person's name, not a shared service account.
• The vendor's own permissions apply per person. Each member's connection can do only what their vendor account can do.
• Precedence: once a member has a working per-user credential, their tool calls use it instead of the shared credential. A disabled per-user credential is skipped. The member's calls then use the shared credential when it is an organization key or Client Credentials (never for Microsoft Azure or Microsoft Graph), or when the member is an Owner or co-owner. Otherwise the call is refused — with personal_sign_in_required when the shared credential is someone's own sign-in, or as not configured when the organization holds no shared credential at all — and the member re-authorizes under Your personal sign-ins where that section still offers the connector (it skips a connector whose organization holds no shared credential at all, except Microsoft Azure and Microsoft Graph).

What has to be true first

Per-user connections have a few prerequisites:

1. The connector must have an active subscription — any tier, including Free, as long as it's active.
2. For HaloPSA / NinjaOne: an administrator must first configure the shared connector in OAuth (Authorization Code) mode on the Connectors page. Members reuse that OAuth app registration — they never need the app's client secret themselves.
3. For Microsoft Azure / Microsoft Graph there is no such prerequisite. These two authorize against StackJack's own registered Microsoft application, so a member can connect whether or not an owner has ever configured the connector. There is no app registration for you to create and no client secret to distribute.
4. The member must have at least one tool assigned for that connector (set on the Team page). Members with no tool access for a connector can't connect to it.

What happens when a member connects

For the sign-in connectors — HaloPSA, NinjaOne, Microsoft Azure and Microsoft Graph — the member selects Connect in their personal sign-ins on the Connectors page, signs in on the vendor's own page, and approves access. On success StackJack:

• Stores the member's personal refresh token as a per-user credential (in Azure Key Vault, isolated to that member).
• On the member's first sign-in to that connection, creates a personal MCP client for them (named "'s key") and shows a one-time credentials page with its Client ID and Secret — displayed exactly once, for up to 5 minutes. The member should plug these into their AI tool immediately (see Your personal connector sign-ins). A member who connects through a sign-in AI app (Claude, ChatGPT, Microsoft Copilot) does not need the key.
• On every later sign-in (Re-authorize or Reconnect), keeps the MCP client the member already holds for that connection: no new client, no credentials page, and nothing changes in their AI tool. At every such renewal StackJack also sets the kept client's tool list to the member's current tools, so a tool or role granted since the first sign-in reaches it. (A hand edit of that one client's tool list on MCP Setup is replaced at the next renewal.) A member who lost the client's secret can select Revoke my key on their personal sign-in card, or an owner or administrator can revoke it under Member credentials on Team; the member's next sign-in then creates a new client and shows it once.

For N-central, the member enters their server URL and personal JWT in a dialog; StackJack validates it on the spot. No separate MCP client is minted for N-central JWT entry.

Maintenance is mostly automatic

• Admin rotates the OAuth app secret? When an administrator re-saves the shared HaloPSA/NinjaOne credential with new app details, StackJack copies the new app configuration onto each member's per-user credential and keeps that member's own sign-in. In the normal case — same server, same vendor, only the client secret changed — members do not have to re-authorize. Three cases fall outside it:
  • A member StackJack could not update during the save is left unchanged. That member's next call fails and their card flips to Re-authorize Required. They can re-authorize themselves, or StackJack support can re-run the copy for them.
  • Changing the server address is not a secret rotation. If the save moves the connector to a different HaloPSA or NinjaOne host, StackJack deliberately refuses to carry members' existing sign-ins across: their tokens were issued by the old host and are not valid at the new one. Every member has to sign in again against the new address.
  • Changing scopes does not re-consent anyone. The new scope list is copied onto each member's credential, but each member's stored sign-in still carries whatever they approved originally. Expect to ask members to re-authorize before a widened scope actually works for them.
• A member's grant gets revoked in the vendor? That member's card in their personal sign-ins flips to Re-authorize Required, and they get an email when re-authorizing is the fix. Only that member is affected — the shared credential and other members keep working.
• N-central JWT regenerated in N-central? Regenerating invalidates the old token — the member (or admin) must paste the new JWT.

Admin-side visibility

Per-user credentials are individually visible to StackJack support, who can also help repair them in bulk if an OAuth app change ever leaves members stranded. Owners and administrators can also see a member's personal sign-ins on Team (the Personal Sign-ins button on that member's row, their own row included) and remove any of them there. The primary owner's row never offers it. If a member leaves your team, their per-user credentials stop working immediately when their membership is deactivated (every request re-checks membership), and orphaned per-user rows are cleaned up automatically the next time the shared credential is saved.