in making authentication end point stateless

Tokenscript Design
1

Old design:

  1. bogotá.hotel backend generates UN, expiry upon request. It stores UN, expiry in server-side.
  2. user submits {useTicket, useEthKey, [UN, expiry]} to the service that requires authentication.
  3. The server checks {UN, expiry} against server storage, then verify useTicket, useEthKey

PROBLEM

@nicktaras wanted bogotá server side to be stateless (no storage) and configurable (with bogotá-sercret)

SOLUTIONS

I proposed New design:

  1. bogotá.hotel backend generates expiry: now + 3600, UN: hmac(expiry, bogotá-secret) upon request. It stores nothing.
  2. [ditto]
  3. The server checks UN == hmac(expiry, bogotá-secret), then verify useTicket, useEthKey

@nicktaras : however, in this case UN is not specific to the current user, that is 𝑎) 2 users who requested UN at the same time (one in Denmark one in Australia) gets the same UN. Also 𝑏) they can share it.

me: Yes, but I don't see how that can be used against us. The users can share UN between themselves all they want as long as they have different tickets and ethereum addresses. However, if 𝑎) is undesirable for some reason (I couldn't think of one), we can alter the protocol to

New design

Providing a signed UN is a bad idea as long as the signed UN is delivered in JWT format, since developers keep thinking signed JWT meant the end status of authentication, not the beginning of it. expiry: now + 3600 UN1: rand() UN2: hmac(concat(UN1, expiry), bogotá-secret) UN: concat(UN1, UN2) upon request. It stores nothing. 2. [ditto] 3. The server checks UN2 == hmac(concat(UN1, expiry), bogotá-secret), then verify `useTicket, useEthKey

(I think to use rand() instead of ticketId or ticketObj , because the unpredicable number better not be related to a ticket, therefore usable to produce one useEthKey that can go with multiple different tickets.)

Issue tracking this development Unpredictable Number Function · Issue #34 · TokenScript/token-negotiator · GitHub