Authentication and authorization

Recall that authentication is the ability to prove a certain identity, and authorization is the ability to access a resource or feature.

Authentication

In a system with multiple components (such as Kchannels), it is desirable not to have to authenticate at every component. This is achieved by federated authentication, and there exist several well-known standards (e.g. SAML, OAuth) for this purpose. Kchannels uses a custom federated authentication mechanism that borrows from both SAML and OAuth in order to achieve a much better user experience. We take advantage of the fact that we are working in a blockchain environment and are performing similar actions (such as cryptographic signing) using our keys.

Kchannels authenticates using a simple challenge-handshake protocol. For this purpose the client requests a challenge from the Zone Manager, providing its (claimed) identity and a random number.

The Zone Manager returns a signed challenge, which includes

• the client's (claimed) identity

• the client's random number

• its own (claimed) identity

• its own random number

• an EIP-712 signature using its identity

The client validates the data, including its own random number, and the signature, verifying it is talking to a known agent, signs the entire message with its own key using EIP-712, and returns it. The Zone Manager validates the data and all signatures, making sure the message has not been tampered with or replayed, and the user is who he claims to be. All this has to happen within a short time window (or the challenge expires), and on successfully doing so it issues a JWT token that is recognized throughout the system. The client attaches the token to every subsequent request, until the token expires.

This mechanism gives us authentication in both directions and even guards against replay and man-in-the-middle attacks in both directions. As of this writing, tokens are valid for 24 hours and can only be renewed with another challenge.

Authorization

Kchannels employs component-level authorization. The JWT merely states who the user is, and each component decides how to authorize a given authenticated request. For example, if a user tries to access another user's channel, the request is denied by the second user's zone. It is important to note that the presence of a JWT in itself does not imply access to anything in particular; it is merely a secure statement of successful authentication vouched for by a trusted party. Also, even when authorized, a JWT is not sufficient to perform anything deemed particularly sensitive, such as perform transactions or create/update channels. For that, additional EIP-712 signatures are needed.

Mandatory transport encryption

As designed, Kchannels already does not allow for a man-in-the-middle or replay attacks to do anything particularly sensitive such as forge a transaction. To stop eavesdropping on traffic, Kchannels additionally requires all communication with end users to employ transport encryption (TLS). Kchannels also employs DNSSEC and CAA records on its domains to ensure clients are reaching the backend correctly. This should be completely transparent to users as both of these have been around for a while and are already well supported.

Integration with third parties

The authentication mechanism described above was chosen for its user experience and operational simplicity, but the dependent Kchannels APIs merely demand a compatible JWT issued by a trusted actor. Authentication within Kchannels is decoupled from the rest of the system such that Kchannels can easily integrate alternative authentication mechanisms, such as username/password, biometric credential, etc. as long as they result in a compatible JWT being issued. As of the time of writing there is no designated "identity server" role; any component is free to generate a JWT good for any other component within a single deployment, although this is also easy to add if ever needed.