37 lines
1.3 KiB
Plaintext
37 lines
1.3 KiB
Plaintext
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
|
|
|
|
|