[Feature]: Reuse token when running on server

[tkurki]

Operating System

Other

Browser

Other

KIP Version

4.6.0

Signal K Server Version

2.23.0-beta.2

Bug Description

Kip does not detect an existing authenticated session but forces the user to explicitly login in Kip.

Steps to Reproduce

1. Login in the Admin UI
2. Navigate to Kip

Configurations screen says Server authentication or Device Token required and Connectivity screen shows Login to server as disabled.

I would expect Kip to recognise the existing session and use it transparently, without any action needed from the user. As this is a prerequisite for configuration sharing I think login should be as smooth as possible.

/skServer/loginStatus returns information about the session, for example

{
    "status": "loggedIn",
    "readOnlyAccess": true,
    "authenticationRequired": true,
    "allowNewUserRegistration": true,
    "allowDeviceAccessRequests": true,
    "userLevel": "admin",
    "username": "XXXX",
    "securityWasEnabled": false
}

PS

Toggling Login to server but then canceling the Sign in to Signal K dialog leaves the Login to server enabled and [Set credential] button enabled.

[godind]

Login will be rewritten at some point and I'll add this. Keep in mind that many users don't run KIP on the servers so there is no token sharing possible, unless
There is a way I do t know about.

[tkurki]

I explicitly meant session, not token, I think the title is now incorrect.

Session authentication has nothing to do with where the browser that runs KIP is running. If I understood correctly what you meant with run KIP on the servers - whether or not the browser is running on another device/computer or the one running the server.

When you login in the Admin UI the server sets a cookie in the browser. This cookie is sent automatically by the browser in subsequent same origin requests. So any requests that KIP makes would be already authenticated, without using a token. So token would not be needed at all.

[godind]

Well maybe it's worth clearing out semantics. Yes, by token I mean adding the jwt to the http request, regardless of where it's sourced from. This is what you call session, right?

Right now, KIP handles this internally. I understand what you're saying about the browser. It will change in the future.

[tkurki]

Yes, by token I mean adding the jwt to the http request, regardless of where it's sourced from. This is what you call session, right?

There's bit more nuance to it. With session I mean the mechanism where

• the server sets a cookie when the user logs in and the cookie's value identifies the session, with path set to / so that the cookie "covers" the whole server
• all subsequent requests to the same server include the cookie automatically, thereby being identified as authenticated - belonging to the same user session
• subsequent requests can be execute by any web page on the same

This works whether or not the browser is running on server or on another device. And it works without every separate web page needing to do login and handle authentication.

What I usually refer to as token is the "token in header" authentication mechanism, where the token is sent explicitly in the Authorization header.

What makes the terminology confusing is that the values in cookie and and in header are both JSON Web Tokens that is more a data encapsulation format.

But terminology aside, what I'd like to happen is that

• user logs in another application, like Freeboard, does not need to be Admin UI
• user navigates to KIP
• KIP recognizes the authenticated, cookie based session

This works now between Admin UI and Freeboard, but not with KIP.

[mairas]

+1 from the Halos/SSO/OIDC perspective.

Halos runs Signal K behind an SSO provider (Authelia) using OIDC. In this setup, users authenticate once via the identity provider, and Signal K accepts the session through OIDC auto-login — setting the usual session cookie. Other Signal K webapps (Admin UI, Freeboard) work fine because they rely on the browser cookie.

Kip is the exception: it manages authentication internally and ignores the existing session cookie. In a pure SSO deployment this isn't just a UX inconvenience — it's a blocker for Kip use (unless the user is happy to use Kip only unauthenticated, that is). Halos users only have SSO credentials; they have no local Signal K username/password to type into Kip's login prompt. Authentication is impossible.

As Teppo described, checking /skServer/loginStatus on startup and honoring the cookie-based session would resolve this.

[godind]

@mairas understood. When you say:

they have no local Signal K username/password to type into Kip's login prompt. Authentication is impossible.

You mean the idea is they should not have to enter a KIP username/password, right? Or do you mean that currently with KIP in Halos "Authentication is impossible".

[mairas]

You mean the idea is they should not have to do it. Right? Or do you mean that currently KIP "Authentication is impossible".

Authentication is impossible. If single-sign-on is used, there are no local users, and authentication does not use username and password.