> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/troubleshooting/sign-in-problems.md).

# Sign-in problems

What to do when the sign-in to the Datasentinel MCP server stalls, expires, or comes back after it worked.

**Applies to:** an assistant that signs in to the Datasentinel MCP server with OAuth, and scripts that send a user token. For the normal flow, see [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md); for certificate errors, see [Self-signed and untrusted TLS certificates](/manual/ai-connector/troubleshooting/ssl-certificates.md). If the sign-in fails at once on a host name you never typed (`getaddrinfo ENOTFOUND`), see [Sign-in fails on an unknown host name](/manual/ai-connector/troubleshooting/sign-in-unknown-host.md).

## The login page stays on "Signing in" after a correct password

The page accepted the password but the browser could not hand the session back to the assistant. Each sign-in link is valid once: after the first submit the link is consumed, so a second click shows *This sign-in link has expired or has already been used*.

Start again from the assistant (its authenticate action, `/mcp` panel or login command), which produces a fresh link. If it happens every time, the browser is blocked from reaching the assistant's callback address, which is a local address on the machine running the assistant: on a remote server, that means the port forward is missing or the session was opened without it. See [Sign in from a server without a browser](/manual/ai-connector/server-setup/how-authentication-works.md#sign-in-from-a-server-without-a-browser).

## "This sign-in link has expired or has already been used"

A sign-in link lives ten minutes, and works once. Both cases end here: a link opened too late, or a page reloaded or submitted a second time. Start the sign-in again from the assistant; do not reuse the old link.

## "Invalid login or password"

The login page shows this generic message for a wrong login, a wrong password, or an account unknown to the platform. Retry on the same page with the credentials you use for the Datasentinel web interface. If they work there but not here, the account may exist in Grafana without being a Datasentinel user: ask an administrator.

## "The MCP add-on is not enabled for this Datasentinel licence"

The platform's licence does not include the AI connector. The sign-in is refused for every user until the licence is updated; nothing is wrong with the account.

## The assistant loops on authenticate

The assistant asks to sign in, the login succeeds, and it asks again, or it reports that the authorization server does not match. This is the server's public URL disagreeing with the address the assistant connects to: the discovery document advertises one origin as `issuer`, the assistant uses another (a DNS alias, an IP address, a name behind NAT). Check what the server advertises:

```bash
curl -s https://<public-host>/.well-known/oauth-authorization-server
```

The `issuer` must be the exact origin your assistants use. If it is not, set `DS_MCP_PUBLIC_URL` on the MCP service, as described in [TLS hostname mismatch on API calls](/manual/ai-connector/troubleshooting/tls-hostname-mismatch.md#the-fix), and register the server in the assistant under that same name.

## The tools fail with a 401 after days without use

A session ends after ten days without using the server. The assistant then shows the server as needing authentication again, or its calls come back unauthorized: sign in again from the assistant, and the session is good for another ten days of use. An administrator ending the session has the same effect.

## A 401 with a user token in a header

A script that sends the platform's user token as an `Authorization: Bearer` header gets a 401 when the token has passed its 24-hour lifetime, because the server never renews it. Mint a new one and update the header; [Refresh the user token automatically](/manual/ai-connector/developers/refresh-user-token.md) does this for a scheduled job. A 401 right after minting means the token is not reaching the server: check the header name and the `Bearer` prefix.

## Where the server logs it

On the platform, the MCP server writes every authentication event to `/datasentinel/log/mcp.log`, one line each, with the client and the user but never the password or a token:

| Event                              | Log line                                                             |
| ---------------------------------- | -------------------------------------------------------------------- |
| An assistant registered itself     | `oauth client registered`                                            |
| A sign-in succeeded                | `oauth login accepted for <email>`                                   |
| A sign-in was refused              | `oauth login refused`                                                |
| A session was opened or renewed    | `oauth tokens issued for <email> ... (code exchange)` or `(refresh)` |
| A session started serving requests | `session opened for <email>`                                         |
| A bearer was rejected              | `bearer rejected on /mcp`                                            |
| A session was ended by revocation  | `oauth refresh token revoked`                                        |

To follow one user's sign-in from the login to the first tool call:

```bash
grep -E 'oauth (client registered|login|tokens issued)|session opened|bearer rejected' /datasentinel/log/mcp.log | tail -50
```

Every line carries the MCP session id, so the same id in later lines ties the tool calls to the sign-in.

For the other lines, and what each failure means, see [Find the cause in mcp.log](/manual/ai-connector/troubleshooting/read-the-mcp-log.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.datasentinel.io/manual/ai-connector/troubleshooting/sign-in-problems.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.