[OAUTH-WG] JMAP's experience with proposing an Authentication model

[Bron Gondwana <[e-mail]>]

(bringing this back to just the OAuth list)

On Tue, Feb 23, 2021, at 23:46, Hannes Tschofenig wrote:
> I don’t know whether it is already too late for your document (which is dated 2016) to consider the use of OAuth but Rifaat and I are happy to put you on the spot in one of our future virtual office hours or virtual interim meetings. 


It's never "too late" - we could add a "how to Authenticate JMAP using OAuth" document easily enough.

That specific document which I mentioned went through many revisions and a split to eventually become RFC8620 and RFC8621.  The core JMAP spec says this about Authentication:

8.2 <https://tools.ietf.org/html/rfc8620#section-8.2>.  Authentication Scheme



   A number of HTTP authentication schemes have been standardised (see
   <https://www.iana.org/assignments/http-authschemes/>).  Servers
   should take care to assess the security characteristics of different
   schemes in relation to their needs when deciding what to implement.

   Use of the Basic authentication scheme is NOT RECOMMENDED.  Services
   that choose to use it are strongly recommended to require generation
   of a unique "app password" via some external mechanism for each
   client they wish to connect.  This allows connections from different
   devices to be differentiated by the server and access to be
   individually revoked.

What it doesn't have is something like what existed in the first draft, which allowed out-of-band authentication in many ways, and *probably did require security review - but security review from people who wanted it to succeed rather than from people who wanted it to go away because it wasn't OAuth*.  At the time, that didn't sound like something achievable.  We were told that any authentication proposal would have to get past the OAuth working group, who would shoot it down or stagnate it for years.  Maybe that was wrong, but it was the impression we got from multiple people in multiple conversations, both in our working group and in the hallway track.

The original authentication protocol started with a username and a service, and got back a session token plus list of authentication methods that were allowed, or even a "we already authenticated you out of band - go right ahead".

The methods included password or password plus second factor, but also allowed for things like "here's a URL, go sign in there and when you're finished your session will be valid" or "a popup has been shown in your existing sessions on other clients, confirm this code and click OK".

The important thing was that there was no requirement that there be any web context built into the client - it could happily just sit there waiting for a push event down the push channel to tell it that the session had been authorised, or poll to see if it was allowed access yet.  The authentication could be entirely out of band after the initial handshake.

It's a quite different model than OAuth2.  It's probably closer to GNAP, which is why I've been watching that with interest, though not with enough time to engage closely.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]