Login Provider and Managed Access Tokens

For autonomous tasks that need to authenticate to an external service, in addition to using shared secrets (e.g. API keys), it is possible to use a per-user access token so that the identity used is the specific user's.

This requires the user to perform a one-time interactive login. The system then caches and auto-refreshes the access token for future use.

Setup

An org admin must set up Login Providers before users can log in to external services:

• From the Web UI, go to Connect / Logins and add providers in the Providers tab.
• Or use the CLI command cs org login-provider create ....

Most OAuth2 providers require registering the Crafting system as a client so that the login flow can be initiated from the Web UI.

Login

Logging in to configured providers should be part of the new user onboarding process. Users visit Connect / Logins and log in to each provider configured by org admins.

Once logged in, the per-user access token can be used wherever per-user login is supported — for example, in the authentication configuration of MCP servers.

Reauth Policy

When setting up a Login Provider, the org admin can specify a reauth policy:

• Enable auto-refresh (only for supported providers), with an optional maximum refresh count.
• Enforce a specific token validity period. The system uses whichever validity period is shorter — the enforced maximum or the validity issued by the provider.

For example, to enforce re-authentication every hour: disable auto-refresh and set Max Token Validity to 1 hour.

See Also

• MCP Servers — using per-user access tokens with MCP server authentication
• Agentic Sessions — autonomous sessions that may use per-user tokens