The future of authentication !

[chibenwa]

Interoperability

TMail do support Basic authentication.

This enables TMail to work with ANY JMAP server.

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:params: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.

Work to do

• Implement the long lived token flow (backend and frontend) upon login
• Ensure we are interoperable with non-tmail servers. DOD: I can use FastMail with the TMail application.
• If com:linagora:long:lived:token then I have an Devices section that displays the long lived tokens and allow revoking the access.

[chibenwa]

Cc @hoangdat thoughts?

[chibenwa]

@Arsnael maybe too ;-)

[hoangdat]

You support this for the target: manage devices to access to TMail backend?

[Arsnael]

No we did not implement that long lived token flow on the backend yet, if that was your question :)

[chibenwa]

The goal would be for TMail users not to use basic auth.

The idea @hoangdat is that TMail mobile app do NOT store the user password when used with TMail backend. Which is much more secure ;-)

The side effect would then be to allow managing devices ;-)

[Arsnael]

@chibenwa looks good overall. Any thoughts on the life of those tokens?

long live token: a month at least I would guess?
short lived JWT token: an hour? a few hours?

[chibenwa]

long live token: a month at least I would guess?

Unlimited? (That's OK IMO as they can be revoked and are only visible once. I hate apps asking me again my password...)

short lived JWT token: an hour? a few hours?

I was thinking 1h.

[hoangdat]

Ok with that. We worked similar in LinShare with permanentToken and JSESSIONID.

1. Create permanentToken at the first time login
2. Get JSessionID from header
3. Using JSessionID to request resources
4. When JSessionID expire, use PermanentToken to get JSessionId again.

[hoangdat]

Unlimited? (That's OK IMO as they can be revoked and are only visible once. I hate apps asking me again my password...)

I think so to have a good experience for user, no need to login and login again

[chibenwa]

Ok with that. We worked similar in LinShare with permanentToken and JSESSIONID.

Yes it is the same flow.

[chibenwa]

I modified the above to allow also generation of short lived tokens with basic auth directly.

This allows web clients to generate secure short lived tokens of their own...

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)

[chibenwa]

I think the backend team should start working on this next sprint - given that dedup + customer stuff will not keep us busy the all sprint...

Thoughts @hoangdat @Arsnael ?

[Arsnael]

We could include that (or at least start talking about it) in tomorrow's grooming yes, sounds reasonable

[chibenwa]

TODO detail login flow for browser...

[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.

[hoangdat]

@chibenwa how about I close this ticket? Or we still keep it in roadmap?