LogicNets as OpenID Provider (OAuth 2.0 / OpenID Connect)
Applications can let users log in with their LogicNets account and then call LogicNets web APIs on behalf of that user. LogicNets acts as an OpenID Provider (OpenID Connect) and OAuth 2.0 authorization server. Typical clients are MCP clients like Claude Code, portals, and integrations.
For a system that calls LogicNets with its own identity (no user), use the client credentials flow instead, see How to Use the OAuth 2.0 Client Credentials Flow Using RS256-signed JWT Bearer.
Register the Application
An administrator registers the application in Access Manager, Server Connections → OAuth Clients (see Access Management Web Portal). The application gets a client id and a client secret and may only use its registered redirect URIs and allowed scopes. Only confidential clients are supported: the application must keep the client secret safe. Applications cannot register themselves (dynamic client registration is not supported).
Discovery
The configuration of the provider, including all endpoints, is available at the following URL:
https://<host>/<company>/.well-known/openid-configuration https://<host>/.well-known/oauth-authorization-server/<company>
Endpoints
All endpoints start with https://<host>/<company>/oauth2token/ and contain the following options:
| Endpoint | Purpose |
authorize |
This starts the login in the user's browser. |
token |
This exchanges the authorization code for tokens and refreshes tokens. |
revoke |
This revokes a refresh or access token (RFC 7009). |
introspect |
This tells the system if a token is still active. |
userinfo |
This returns information about the logged-in user. |
keys |
This is the public keys to verify token signatures. |
logout |
This logs out the user. |
Log In the User (Authorization Code flow with PKCE)
The application sends the user's browser to the authorize endpoint, which looks as follows:
GET https://<host>/<company>/oauth2token/authorize ?response_type=code &client_id=<client id> &redirect_uri=<a registered redirect URI> &scope=openid profile email offline_access &state=<random value> &code_challenge=<BASE64URL(SHA256(code_verifier))> &code_challenge_method=S256
PKCE (
code_challenge,code_challenge_method=S256): LogicNets strongly recommends this option, as it prevents a stolen authorization code from being used.scope: You may leave this out, as the system always adds the client's default scopes. An application may also send
resource(the URL of the API it wants to call). LogicNets then adds the scope required by that API.
The user logs in (also via a configured identity provider) and, the first time, sees the consent page. LogicNets then redirects the browser to the redirect URI with code and state. The application exchanges the code, server-side, within a short time:
POST https://<host>/<company>/oauth2token/token Authorization: Basic BASE64(<client id>:<client secret>) Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=<code>&redirect_uri=<same redirect URI>&code_verifier=<code_verifier>
You may send the client id and secret as client_id and client_secret form fields. The response contains access_token, token_type (bearer), expires_in, id_token (with the openid scope), and, depending on the scope, refresh_token. The application calls LogicNets web APIs with Authorization: Bearer <access_token>. Treat the access token as opaque.
Scopes and Staying Connected
| Scope | Refresh Token |
offline_access |
With this the application stays connected. The refresh token works until it has not been used for 90 days or at a limit you can configure per client and per company. The system provides a new refresh token for every refresh, and the old one stops working. Every refresh provides a new refresh token, while a request with the old token within 60 seconds (two parallel requests) still succeeds. Logging out of the browser does not end the session, unless the client is configured to do so. |
online_access |
The refresh token works as long as the user's LogicNets login session (keep-me-logged-in) is active. The refresh token ends when the user logs out. |
| neither | There is no refresh token and the user must log in again when the access token expires. |
Other common scopes include openid, profile, and email, and the client never receives scopes that are not in its allowed scopes. You can set the company default for the offline_access lifetime in settings.cfg:
_session = { authentication = { oauth_refresh_token_lifetime_days = 90, }, }
Refresh and Revoke
Always store the new refresh token from the response.
POST https://<host>/<company>/oauth2token/token Authorization: Basic BASE64(<client id>:<client secret>) Content-Type: application/x-www-form-urlencoded grant_type=refresh_token&refresh_token=<refresh token>
When the user disconnects in the application, revoke the token using the following:
POST https://<host>/<company>/oauth2token/revoke Authorization: Basic BASE64(<client id>:<client secret>) Content-Type: application/x-www-form-urlencoded token=<refresh token>&token_type_hint=refresh_token
Users can also revoke an application themselves under Account → Connected apps, and administrators can revoke an application under OAuth Clients.
Errors at the Token Endpoint
The following table lists possible status details.
| Status | Error | Meaning |
| 401 | invalid_client |
Wrong client id or secret provided. |
| 403 | invalid_client |
The client is not registered or is disabled. |
| 400 | invalid_grant |
The code or refresh token cannot be used anymore. The user logged out (online_access), the grant was revoked or expired, the refresh token was replaced, or the code_verifier does not match. |
| 400 | invalid_request |
Missing or in correct parameters, e.g. the request contained a redirect URI that is not registered or a code that was already used or retrieved too late. |
After invalid_grant the application must require the user to log in again.
Calling LogicNets APIs and MCP Servers
When a protected LogicNets API or MCP server is called without a valid token, it answers 401 with a WWW-Authenticate: Bearer header that contains resource_metadata (where the application finds how to log in for this API, RFC 9728) and scope (the scope the API needs). MCP clients use this to start the login by themselves.
Reply
Content aside
- yesterdayLast active
- 2Views
-
1
Following
