Fwd: Authentication to gmail fails with example app · Issue #239 · jstedfast/MailKit

vấn đề khi login vào gmail bằng OAuth2, và vài suy nghĩ về OAuth2 của tác giả MailKit (jeff)

kết quả là sẽ không có sample login dùng Google Mail 

Thử cái khác đi 

https://github.com/jstedfast/MailKit/issues/239

I guess if you trust browser controls more than email clients, then I suppose that's more "secure"... but it sounds more like the "security" strategy is to not allow passwords to be saved, which means you could just make clients not save the password and prompt every time. In other words, OAuth2 is really just a kludge to work around the fact that many email clients offer to save the user's password for their own convenience (just like web browsers do) and some people feel that by forcing users to enter their credentials manually every time, it makes it more secure? In my experience, that means most users just choose easier passwords to remember (meaning less secure) or they tell their browser to save it (overriding the whole purpose of the OAuth2 security strategy), or... at best, they just store it in something like 1Password or LastPass (which is what I do). Apparently security experts don't feel it's very secure. OAuth 2.0 doesn't support signature, encryption, channel binding, or client verification. It relies completely on SSL for some degree of confidentiality and server authentication. OAuth 2.0 has had numerous security flaws exposed in implementations. The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable. The first sentence suggests to me that the purpose was to enforce the idea that passwords aren't sent over the wire in the clear, thus allowing non-SSL/STARTTLS IMAP clients to login w/o the use of a cleartext password (such as the LOGIN command or the LOGIN and/or PLAIN SASL mechanisms). The solution, here, though, is to simply not support those mechanisms on the server and to instead only offer mechanisms such as CRAM-MD5, SCRAM-SHA-1, NTLM, or one of the many other challenge-response mechanisms that do not send any form of the password across the wire at all. The only counter-argument that I can think of for that (and I'd have to double-check to confirm) is that all of those SASL mechanisms require that the server be able to get access to the raw password string which means that it'd have to store the cleartext password somewhere (e.g. /etc/shadow) whereas in cases where the authentication protocol requires the raw password be sent, then the server could just store a hash of the password and hash the raw password that it receives across the wire and match it against what it has in its database. But that just trades trust in the server not being compromised with a much more likely scenario of the SSL protocol being compromised or a MITM attack. I haven't read what the security experts have said about OAuth2, but my guess is that I'm probably pretty close :-)

OAuth(2) was never designed for native apps. The problem you described "where do i put my client secret/credentials/api key" is not only a problem for a test app that is published on github. It is a real problem for all native apps, if you know how easy it is to "decompile" apps. This applies to interpreted languages like C# and Java even more. OAuth(2) was (sadly) designed for server-to-server communication, where the OAuth credentials are never shipped to a client/user and are instead some where ("safe") in your backend code/config.