Session Control in HAT


Hi @andrius, @snaiste,

Currently, some of the owner-specific API calls requires the User and Password to be transmitted for authentication purposes. This causes HAT-applications to have to store User/Password data in its session. This is inherently unsafe and cumbersome.

I propose a Session Control function set to be build into HAT Core.
This function set would include

  1. A login function, returning a session token
  2. A logout function
  3. SessionAuthenticationHandler, which uses the sessionToken (in place of the current User/Password authenticationHandler).
  4. The sessionToken should auto-expire.

A SessionControl in HATcore makes the end-user applications that Noggin is building much more user friendly.

The question is
a. does HATDex want to code this?
b. or have Noggin code this?

Happy New Year!

Best regards,



I like to add further as shared with Xiao before that who is best to do this will depend who can get it done soonest esp to be in time for Noggin’s v2 launch…

Of course regardless, Noggin will provide to the specification of the session control component.



If we are doing this, it may be worthwhile to plan for a session scheme that also accomodates single-sign-on across a number of systems (so that HAT could be used as the authentication provider for other systems or another trusted system could be used as the authentication provider for HAT).

The single-sign-on capabilities are interesting for HPP-type applications that want to offer services to HAT owners. Those could then forgo their own authentication mechanism and rely on the HAT session

A scheme that has recently gained popularity are JSON Web Tokens ( )

With that, HAT could issue a signed claim to the user that includes her account id (i.e. email) and that could be used as a session token for HAT and other relying parties.

Conversely, HAT could be set up to trust signed claims from a separate authentication component (which could enforce additional measures such as 2FA)

The main advantage over “traditional” session tokens are that the system is stateless (no shared database required), the main disadvantage is that there is no good way to implement “logout” or revokation (tokens will remain valid until the specified expiration date, so the token needs to be short-lived or there needs to be a separate and revokable refresh token).


Yes, not sure if @Terry_Lee has relayed our conversation yet, but I was in fact talking about JWT for precisely such functionality - I am very much in favour.

In my opinion this would provide one of the most straightforward ways of decoupling user login from authentication and authorisation of the rest of the interfaces and has the benefit of being a relatively straightforward and standard protocol.

My main remaining open question here is application authentication flow as I haven’t thought it through completely and income would be very welcome…