Token authentication stops strangers from using your Jupyter server, because access to the server means running arbitrary code. It is on by default and the token is printed in the terminal. It does not protect a token you paste into a chat, a log or a shared screen.
How it works
The Jupyter Server documentation says access to the server means access to running arbitrary code, so access must be restricted. It uses token based authentication, on by default. At start, the server generates a token and logs a URL containing it. You can supply the token in three ways: an Authorization header, a URL parameter, or the password field of the login form.
After you visit the URL once, a cookie is set and you do not need the token again, unless you switch browsers, clear cookies, or start a server on a new port. The command jupyter server list shows the tokens and URLs for your running servers.
Password instead of token
You can set a password with jupyter server password, which stores a hash in a config file. The documentation notes that if you enable a password, token authentication is not enabled by default.
It is possible to turn authentication off by setting the token and password to empty strings. The documentation marks this as not recommended, unless authentication or access restrictions are handled at another layer of your web application.
Where tokens leak
| Place | Why it matters |
|---|---|
| Terminal scrollback and CI logs | The startup line contains a working URL |
| Screenshots and screen shares | The address bar shows the token |
| Browser history and bookmarks | The URL carries the token as a parameter |
| Tickets and chat | Copy and pasted launch links |
| Server list output | Prints live tokens for running servers |
Steps to tighten a setup
- Never log the startup URL in shared logs. Mask it in CI output.
- Bind the server to localhost and reach it through a tunnel or an authenticating proxy, not an open port.
- Use HTTPS if the server is reachable beyond your own machine.
- Stop servers you are not using, so tokens do not outlive their purpose.
- If a token or password may have been exposed, restart the server to get a new token and change the password.
- Never run with both token and password empty on a reachable host.
What a token does not do
A token is a single shared secret per server. It does not tell you which person did what, and it does not limit what an authenticated user can run. Anyone with the token has the server account's access, as the companion post on the execute permission explains. For a network exposure checklist see /resources/blog/jupyter-server-exposed-to-the-network-checklist.
Safeguard does not scan for secrets, so use a dedicated tool for finding exposed tokens. For the dependencies in your notebook projects, try the free scan at gold.safeguard.sh/scan.
Quick check
Does setting a password keep token authentication on?
By default, no. The documentation says that with a password enabled, token authentication is not enabled by default.
Is it fine to disable both token and password on a laptop?
The documentation says it is not recommended unless another layer handles authentication or access restrictions.
Sources
- Security in the Jupyter Server, Jupyter documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
