Secure authentication (mobile)

[chibenwa]

CF https://github.com/linagora/tmail-flutter/issues/28

TMail backend offers better option

GIVEN the user never used the app
THEN the user is prompted for the URL / login / password

The first call is done with basic authentication to get the session (credential are so far kept in memory on the device side)

If the session contains the com:linagora:long:lived:token then the client does a second call (authenticated with basic auth):

[ "LongLiveToken/set",
   { "create": {
      "accountId":"erivgeruferf",
       "clientId": "My android device"
       }
    }, "#0"
]`

Will return :

[ "LongLiveToken/set",
   { "created": {
       "id": "whatever",
       "token": "xxxyyyzzz"
       }
    }, "#0"
]

TMail mobile then stores this long lived token. Given that token, TMail will not need user input upon connection.

This long lived token can be used to generate short lived JWT token that can be used for auth.

Example:

GET /token?type=shortLived&deviceId=xxxx

Authorization: bearer xxxyyyzzz
(note: here only the long lived token and basic auth can be used as a bearer )
(note: basic auth support enpowers secure web access, as in a browser storing long lived tokens is a bad practice...
    allowing basic auth here would allow web clients to create short lived tokens straight after the auth form
    of course, the use of basic auth here is of no use to the mobile team... When using basic auth, device id is ignored 
    and can be missing)

Will return:

{ 
   "token": "aaaaabbbbccccc",
   "expiresOn": "2020-08-17T11:39:40.906+07:00"
}

(if the device id matches, fails otherwise) - (also please note that this token will need to be frequently renewed ;-) frequent renewal enforce security.)

And follow up requests can be done with:

Authorization: Bearer aaaaabbbbccccc
(note: here long lived token usage is REJECTED)

Note that one:

• Might list long lived token
• Value of a long lived token is return by created, and not accessible to JMAP clients after. This ensures one do not use the
• Long lived tokens can be deleted to revoke access of a given device

Eg:

[ "LongLiveToken/get",
   { 
      "accountId":"erivgeruferf"
    }, "#0"
]`

Will return :

[ "LongLiveToken/get",
   {
      "accountId":"erivgeruferf"
      "list": [
       {
       "id": "1",
       "clientId": "My android device"
       },
       {
       "id": "2",
       "clientId": "My IOS device"
       }
    }, "#0"
]`

To revoke access to my IOS device:

[ "LongLiveToken/set",
   { 
      "accountId":"erivgeruferf",
      "destroy": ["2"]
    }, "#0"
]`

And again, if the account do not support this extension, we NEED to support basic authentication.

[chibenwa]

Issues:

• Ability to sign JWT tokens in Java
• LongLivedToken repository (API, memory, contract)
• Cassandra implementation for long lived tokens
• LongLivedToken/set create
• Implement a LongLivedToken authentication strategy
• Implement GET /token endpoint (long live token auth only)
• Implement GET /token endpoint (long live token auth + basic auth)
• LongLivedToken/get
• LongLivedToken/set destroy

[chibenwa]

TODO write an ADR for TMail

[chibenwa]

See https://github.com/linagora/james-project-private/pull/226 for the ADR

[chibenwa]

Flow details

Authentication against a TMail server (first connection)

• 0. Given a virgin TMail application
• 1. The user inputs URL, login and password
• 2. A first request is made to the session object to check if long lived tokens are supported. Basic authentication is used for that request.
• 3. Given that long lived token are supported, a JMAP call is made to create a long lived token. This long lived token is stored.
• 4. The long lived token is used to generate a short lived JWT token that can be used to autheticate all other JMAP requests.

Authentication against a TMail server (later connections)

• 0. Load the long lived token from storage
• 1. Generate a short lived JWT token with it.
• 2. Start doing JMAP calls to load emails and mailboxes (authenticated with the short lived token).

Authentication against a regular JMAP server (first connection)

• 0. Given a virgin TMail application
• 1. The user inputs URL, login and password
• 2. A first request is made to the session object to check if long lived tokens are supported. Basic authentication is used for that request.
• 3. As the long lived token capability is nowhere to be found we store the login and passord localy.
• 4. Basic authentication is used for all following JMAP requests.

Authentication against a regular JMAP server (later connections)

• 0. Load the login/password from local storage.
• 1. Start doing JMAP calls to load emails and mailboxes using Basic authentication.

     Web authentication against a TMail server

• 1. The user inputs login and password
• 2. A first request is made to the session object to check if long lived tokens are supported. Basic authentication is used for that request.
• 3. As the long lived token are supported, a request is made to request a short lived token. Basic authentication is used for that request.
• 4. Start doing JMAP calls to load emails and mailboxes (authenticated with the short lived token).
• 5. Once the short live token is expired the website need to re-ask user login/password and re-create a new short lived token.

Web authentication against a regular JMAP server

Use of basic authentication.