MBOX-Line: From arnt at gulbrandsen.priv.no  Wed Apr 30 00:44:02 2014
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] OAUTH and IMAP
In-Reply-To: <53608FE7.8090909@verizon.net>
References: <53608FE7.8090909@verizon.net>
Message-ID: <91126e57-0707-4038-9696-dda82a1f7aae@gulbrandsen.priv.no>

> * Authorization endpoint: Arguably the biggest flaw in the 
> entire process is that I see no way to build the HTTPS request 
> to an OAuth authorization endpoint without hardcoding specific 
> values.

+1 on this.

> * Refresh tokens: Google's documentation on this is vague. At 
> times, it implies that these last essentially forever unless the 
> user revokes access. At other times (and apparently in 
> experiments), it seems that these last only for long-ish terms 
> (e.g., a few weeks).

Both are sort of true: Every time you use the refresh token you restart the 
clock.

You may look at it like this: The access token is short-lived and often 
exposed on the wire. But if snooped, the snooper has only brief access and 
cannot extend the access period. The refresh token is exposed less often, 
but is valid for a long time. It's like a client-specific revocable 
subpassword.

I implemented it and quited liked the behaviour.

Arnt


