1

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?

  • So your main question is regarding replay attack? – DannyNiu Dec 2 '19 at 9:01
  • @DannyNiu I'm asking what other attacks is this vulnerable to. In theory, assuming the communication is encrypted, the replay attack isn't an issue as the only entity that could get the token would be the one entity that can use it. – ldgabbay Dec 4 '19 at 21:21
  • I'm drafting an answer, in the mean time, could you tell us what your distributed application consist of and in what hierarchy? – DannyNiu Dec 5 '19 at 6:10
  • I've migrated this question here (from crypto) because it seems more about the contents of the signed token than anything else and answers seem to focus on the security of the parties rather than any specific algorithm. – Maarten Bodewes Jan 4 at 14:55
0

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.