Idea: enable derivation of short-lived authentication for frontend user from a server-side credential

[mpizenberg]

Problem
The current offer seems to only enable creation of identified bearer tokens from the website. Those bearer tokens can then be used to make identified requests. In order to make these requests directly from a user’s client web page, the authenticated token is thus revealed to the app users.

Solution
It would be cool if there was an authentication method available that enables derivation of temporary unique authenticated tokens. These can be sent to web clients without revealing the long-term original credentials from the server.

Alternatives
One alternative is to forward all requests through an app server. This double the network traffic and round-trip times. As well as has poor scaling performances since now both the app and Koios need scaling infrastructure instead of just Koios.

[mpizenberg]

Biscuit was suggested to me by a colleague today. What do you think of it?

[rdlrt]

The original implementation (per-release stages) already included a concept that consisted of issuing ticket granting token that allowed user to create further custom aged tokens on their ends (similar implementation as auth0 - the generation of these master tokens were synched across all monitoring instances.

Due to feedback from [then] primitive usage by consumers, we ended up simplifying and using trustless JWT that act as a running token that wouldn't need any centralized component.

While switching back to original behaviour wouldnt take long - the concern now is primarily gonna be handling a change in authentication mechanism from consumer pov, wherein we'd have to potentially come up with 2 implementations for a while and keep them both monitored and added to same counters, which I'd like to merge with a self-runner adding himself dynamically against koios lite.

One alternative is to forward all requests through an app server

I think that's not even an option given the drawbacks. We'd much rather get these tokens wrapped under a secondary token instead, but the simplest solution is adding an endpoint that allows you to generate custom tokens using the initial token provided by UI

[rdlrt]

Biscuit was suggested to me by a colleague today. What do you think of it?

On initial look - this looks very similar to original implementation (wrt offline secondary key generation), will have a deeper check how it differs

[mpizenberg]

Here is a library using biscuit for delegated identity management https://www.hessra.net/blog/delegated-agent-identities

[mpizenberg]

Hello, have you had any chance to have a look at this recently?

[rdlrt]

Yes - part of what we're considering at 1.5.0 (not using biscuit)