Viability of simplified JWT

Question

Our team has been building a custom distributed authentication mechanism, and I wanted to ask if this approach is actually viable. The approach is a dumbed down version of Jason Web Token (JWT). Assuming the user has identified himself to an authentication server, the server creates this payload:

{
  "iss": issuer (the authentication service that authenticated the user)
  "aud": audience (the resource service permitted to accept this token)
  "exp": expiration time
  "sub": subject (the user id)
}

The authentication server then signs this payload (hardwired to libsodium) and creates a token containing the payload and the signature. Then, any service/audience that wishes to accept these tokens can identify the user and verify it with the authentication server's public key. By specifying the audience, it prevents one resource server from replaying the token to another.

Is this reasonably secure? Anything blaring stand out?

Answer 1

Your scheme looks just like a JSON-serialized client-side certificate with all the usual bells and whistles - it includes issuer, subject, validity period, and usage.

To securely use authentication tokens, one must meet at least the following 4 requirements.

1. The token is cryptographically unforgeable (by any reasonable adversary).

2. The authentication server (authentication source) must correctly implement access control(s).

3. The service hosts are honest.

4. The token cannot be reused past certain reasonable amount of time.

The part I suggest look into would be defence against dishonest servers. Possible attacks include man-in-the-middle data capturing and modification. This should be the responsibility of the client who must verify the authenticity of the servers.

Answer 2

The part you described seems sound. Nothing blaringly wrong I see.

Many things are unspecified: You didn't mention how the authentication is done, how communication is done, how signing is done. How does the client request the token, could a MITM request more tokens on behalf of the client? How are servers authenticated? How is the authentication server public key distributed? Where is the token saved client side? When will it give it up(e.g is it in a cookie).

Most but not all of the issues above can be addressed by saying lets do all communication over TLS with proper certificates.