https://bugs.kde.org/show_bug.cgi?id=377382
--- Comment #11 from Pali Rohár <pali.ro...@gmail.com> --- On Thursday 09 March 2017 07:24:37 Thomas Lübking wrote: > https://bugs.kde.org/show_bug.cgi?id=377382 > > --- Comment #10 from Thomas Lübking <thomas.luebk...@gmail.com> --- > Evolution has OAUTH2 support - it's not exaclty proprietary (that wouldn't > make > sense) but it's certainly far from unobjected, see > https://en.wikipedia.org/wiki/OAuth#Controversy OAUTH2 RFC does not specify exact steps for implementation and specially how to exchange and generate tokens. That RFC is too vague for such things, but show examples... Basically we can say that for usage of OAUTH2 you need proprietary extension + try to interpret vague RFC specification for OAUTH2. And IIRC more vendors needs different client implementation of OAUTH2... > Leaving the complexity concerns aside, there's certainly usecase for such > system, but it's not "your MUA wants to log into your IMAP server" but more > like "webservice foo wants to use your google drive" which you can then > individually permit and revoke that permission w/o having to expose (and thus > later change) your credentials. > > Also I frankly wonder how google secures the OAUTH2 access of MUAs - > "something™" will have to open a 2nd channel to google and have it ask for > confirmation. >From my understanding of OAUTH2: this protocol is not designed for open source MUAs, but for servers which must not disclose their parts of authentication/token material. Or for closed source application which must contains data which must not be disclosed to user. If you want to use your own application (which is fully under your control) for OAUTH2, then you send just plain text token in protocol (e.g. IMAP) to server (which is equivalent of user+password). And via other channel (HTTP) you need to request for such token. Google's implementation: On Google console website you need to register your application. You will receive public and private tokens for your application. Application tokens then will be used for requesting user tokens (via web page! with user input). This token is IIRC with infinite validity but Google can revoke it at any time. And with this (your private) token you can request via HTTP REST API for time-limited authentication token, which is then used in application protocol for login (e.g. in IMAP). Note that for requesting authentication token you just need to know your private user token and public application. So once your private user token will be stolen anybody can login to your account (if know application). Which means private application token must be kept secret and to correctly use OAUTH2 either application must be closed-source and had obfuscated private application token in binary (and it cannot leak!) or every user generates your own application token (this is only one solution how to properly implement OAUTH2 for open source application). Server needs to have ability to revoke application token at any time. > If "someone" is your local client that opens a browser with a google link, I > could imagine this is easily broken (by the local client never opening a > visible webpage and just clicking "ok" for the user...) - so the client would > have to tell the user "please log into your google account and allow me" This is used for requesting user tokens and caller needs to know private application token. In case whole service is running on server, then user does not see private application token, it is exchanged between Google server and service server. And if correctly implemented, this step is needed only once. From requested token you can request (now without application private parts) time-limited access token which then you will use in IMAP (or other protocol) for authentication. Basically server can track for which protocols is application token (and derived tokens) applicable. If you think more about it you should realise that it is too complicated, hard to properly implement and it has zero benefits for desktop applications (comparing to plain text user+password auth). Security throw obscurity and obfuscating plain text auth in user's applications binaries does not work. And you can perfectly implement time-limited protocol specified access via user+passwords also on server without need for such thing like OAUTH2. So I see absolutely no reason why desktop email client should implement such thing like OAUTH2. It does not bring any security (comparing to plain text), plain text token can be stolen in same way as plain text passwords and proper implementation needs for user to generate application tokens via some Google console service. If you want to use more secure authentication then look for SCRAM-SHA-256 which does not send any plain text information via (IMAP) application protocol. And not for OAUTH2. PS: Probably I used another terminology as specified in OAUTH2, I just wanted to show how such complicated thing is working to answer Thomas's questions. -- You are receiving this mail because: You are watching all bug changes.
