Server Connection

Through the Access Management function you can manage the external accounts that packages can use on your local instance to authenticate themselves with remote systems. The external account (the calling instance) is the counterpart of the server account (the called instance). You set this up on the Server Connection tab in the Access Management portal.

Access Management has a wizard to connect two LogicNets systems with each other. You initiate this wizard on the source system (the instance doing the calling). The target asks you for the target server address (e.g. https://<hostname>/<company>) and the purpose of the account. The target or called server claims the required user rights based on this purpose.
 

The system generates a RSA-key pair and sends the public key and purpose to the target server. The user logs in to the target server and is asked for consent.
 

The system creates a server account on the target instance after the user gives consent and stores the the provided public key as an authentication key. Then the browser redirects the call back to the source instance and creates an external account on the source instance together with the private key.

A client application/project can use the ‘authentication.external_users’-part to retrieve the password/authentication bearer and pass that bearer via the call-webservice part. It is also possible for you to add external accounts manually. You use this option when the target system is not a LogicNets-based system and does not support automatic account creation.  

OAuth Clients

LogicNets can act as an OpenID Provider, where other applications let users log in with their LogicNets account and then call LogicNets on behalf of that user. Examples include MCP clients like Claude Code, portals, and integrations. You must register each such application as an OAuth client under Server Connections → OAuth Clients.

Register a Client

Click New and fill in:

• Client id: Leave this field empty and the system generates one. LogicNets then creates a server user for the client with a generated client secret. The system shows the secret once, right after saving it. Copy it with the copy button and give it to the application owner. The system only stores a hash of the secret.

• Name: This is what the system shows to users on the consent page and under Connected apps, e.g. Claude Code.

• Status: Active or Disabled. A disabled client cannot log users in or refresh tokens.

• Redirect URIs: Enter one per line, using the exact addresses the application may return the user to. Use https. For applications on the user's own computer (command-line tools such as Claude Code), http://localhost/... or http://127.0.0.1/... is allowed, with any port; the rest of the address must match exactly, e.g. http://localhost/callback.

• Allowed scopes: Enter these separated by spaces, e.g. openid profile email offline_access. * allows every scope. The client never gets more than this.

• Default scopes: This is always added to what the client asks for. Set offline_access here for an application that must stay connected (many MCP clients do not ask for it themselves).

• Consent: Ask the user once. This means that the user sees a page that explains what the application may do, and decides their action. Use Skip (trusted first-party client) for your own applications.

• Refresh token lifetime (days without use): This is only for offline_access. Empty = the company default, which is 90 days.

• End offline_access grants on logout too: By default, a user stays connected in the application when that user logs out of the browser. Select this option to end the connection at every logout.

• Legacy: This is the behavior of previous LogicNets versions and is a refresh token without offline_access that ends at logout. It is only for existing integrations that rely on it.

Connected users. Select a client to see the users who connected with it, when they connected, and when they last used it. Revoke ends one user's connection, Revoke all ends all user connections and the application must then ask for the user's permission again.

Reset secret creates a new client secret and the old secret immediately stops working. Delete removes the client, its server user, and all its connections.

Existing clients. In previous versions, a client was a server user in the user group system.idpclients. Such clients are registered automatically, keeping their client id and secret and their old behavior (all scopes, no consent page, legacy refresh). Review them and add their redirect URIs.