Your own MCP client (OAuth setup)

This page is for developers and organizations that want to connect their own MCP client to the Autosignly MCP server, rather than using a ready made surface such as the Claude directory connector or Claude Code.

The server is a standard remote MCP endpoint protected by OAuth 2.1. Your client signs in as a 16it user and acts on that user's behalf, scoped to the company it selects, always on the production environment.

• MCP endpoint: https://mcp.16it.eu/mcp (Streamable HTTP, Bearer token)
• Authorization server (Keycloak): https://auth.16it.eu/realms/prod-16it

Step 1: Request an OAuth client

The server does not allow self service (dynamic) client registration, so the first step is to ask 16it to register an OAuth client for your integration. Send an email to [email protected] with:

• Integration name and a short description of what it does.
• Client type:
  • Public + PKCE for a native, desktop, mobile or CLI app (no secret stored on the device).
  • Confidential for a server side integration that can keep a client secret safe.
• Redirect URI(s) your client will use after login. Loopback (http://localhost:<port>/...) is fine for native and CLI apps.
• A contact for the credentials handoff.

We create the client in the prod-16it realm and return:

• your client_id,
• a client_secret (confidential clients only, delivered over a secure channel).

Step 2: OAuth and discovery details

Most MCP clients discover everything from the server. On an unauthenticated call the endpoint answers 401 with a WWW-Authenticate header pointing at its protected resource metadata, so a compliant client can find the authorization server on its own:

• Protected resource metadata (RFC 9728): https://mcp.16it.eu/.well-known/oauth-protected-resource
• Authorization server metadata (RFC 8414): https://auth.16it.eu/realms/prod-16it/.well-known/openid-configuration

If your client needs the endpoints explicitly:

Setting	Value
Authorization endpoint	https://auth.16it.eu/realms/prod-16it/protocol/openid-connect/auth
Token endpoint	https://auth.16it.eu/realms/prod-16it/protocol/openid-connect/token
Scopes	openid profile email (add offline_access for a refresh token)
Flow	Authorization Code. Public clients must use PKCE (S256); confidential clients authenticate with the client secret.
Resource / audience	The backend validates the token issuer and signature, not a specific audience, so no resource parameter is required.

Step 3: Connect

1. Run the standard Authorization Code flow against the endpoints above with your client_id (and PKCE for public clients). The user signs in with their 16it account and approves.

2. Exchange the code at the token endpoint for an access token (and a refresh token if you requested offline_access).

3. Call the MCP endpoint with the token:

   POST https://mcp.16it.eu/mcp
   Authorization: Bearer <access token>
   Accept: application/json, text/event-stream
   Content-Type: application/json

   Start with initialize, then tools/list, then tools/call. Company scoped tools take a companyId argument that you read from autodocuments_list_my_companies.

4. Refresh the access token with the refresh token before it expires; there is no separate API key to rotate.

Acting for your users

If you are building a product that serves several users, run the Authorization Code flow once per end user. Each of your users signs in with their own 16it account and your app stores that user's refresh token. A few consequences:

• You never receive a master credential that reads every tenant's data. Each token is scoped to exactly what that individual 16it user may access.
• A confidential (server side) client is the right choice here: keep one client_id / secret for your product and obtain a separate per user token through it.
• Use offline_access so your backend can keep acting for a user between sessions, and refresh each token before it expires.

What the client can do

The server exposes a focused tool set, the same across every surface:

Read

• List the companies the user belongs to
• List and read document templates, with their labels (tags)
• List and read documents, with signing status, and their attachments
• Look up the counterparties (companies and people) the user signs with
• Check signature rules per country and SMS coverage

Create / send

• Create a document template (from HTML)
• Generate a document from a template
• Organise work with labels (tags) and manage a document's attachments (list, reorder, remove)
• Send a document for signing (SES / AES / QES, eIDAS compliant)

Data and permissions

• The client acts as the signed in user and can only do what that user's 16it account can do.
• Every company scoped action is limited to the company passed in the call.
• The server always works on the user's production environment and can never reach a sandbox.
• Responses return only the fields listed in the privacy policy; signatory e-mail addresses and phone numbers are never returned.

note

Each integration gets its own OAuth client. If a secret is ever exposed, ask 16it to rotate it; this does not affect other integrations.