On 2024-07-31 07:49, Andrew C Aitchison via mailop wrote:
On Sun, 14 Jul 2024, Scott Q. via mailop wrote:

My question wasn't geared in that direction. It's up to each
provider to create their own custom interfaces for integrating all
that. It's not rocket science.

My question was geared towards the clients used to access mail.

Outlook uses hardcoded integration with Gmail, Yahoo too I think from
the strings I saw in a dll.

But that integration doesn't have anything special, it's basically
Outlook making a post like this:

        'client_id':
445112211283-61c9mrk8i55mfr882g61p37m8j2nga3q.apps.googleusercontent.com

        'login_hint':
        u...@gmail.com

        'redirect_uri':
        http://localhost:8011

        'response_type':
        code

        'scope':
        profile email https://mail.google.com

        'rs':
        en-US

        'build':
        16.0.17726

        'platform':
        Win32

        'app':
        Outlook

That looks like a custom implicit flow where Outlook has that
client_id and it goes to URL
: https://accounts.google.com/o/oauth2/v2/auth
Mind you, that URL can be derived
from https://accounts.google.com/.well-known/openid-configuration since
it's nothing more than the authorization endpoint.

Taking another example, eM Client. They seem to use Authorization Flow
with Yahoo. Pretty straightforward.
User adds a Yahoo account, eM Client opens the Yahoo oauth login page,
if login is successful Yahoo posts the token to eM Client's oauth
server which in turn passes it over to the eM Client app.

Again, I'm not oauth expert but I can't figure out why this can't be
done with all providers.

Well, there are several reasons why providers have not drank the oAuth koolaid, for better or for worse. Might be a good excuse for a M3AAWG survey, on why they don't.. but if you trust our impresssions, from all the conversations we have with email providers..

* Don't want the extra work to implement oAuth servers
* Afraid of maintaining an oAuth server
* General 'its complicated' comments
* Suspicious of 3rd party oAuth providers
  - data tracking, security breaches, et al
* Don't want to confuse customers with changes

Remember, we are talking about an industry and customer base that is adverse to change. Heck, hard enough to get them to shut off allowing plain text logins over the wire.. or rDNS for their CPE equipment.. 20 years later..

You say it isn't 'rocket science'.. maybe not to us, but to a lot of people it is.. and when you have a C-Suite that says, if it isn't broke, don't fix it..

This isn't a 'technical' problem per se.. there are a lot of good technical ideas that simply aren't getting adopted.. which is why we have proposed alternatives that might be easier to adopt..

We push for better security every day with providers, but unless it is transparent and painless and simple.. don't expect them to jump on ANY bandwagon.. good or bad.

Amazing how even governments and other organizations you think would be more forward looking have the same attitude, when you discuss this with their engineers..


I agree that it would be good if this worked for all providers.

Thinking about adding this to alpine and fetchmail, which are not apps
and don't have active servers for Yahoo to do an oauth login.
I assume that the provider can pass the token directly to the client
making the connection ?

Currently this step is quite ragged and not easy for users.

GMail particularly makes it hard.
There are T&Cs and a contract which requires details of the non-existant
web service providing the backend to the non-existant App. There are stories of the authorization dying after a week, and users
winding up at instructions which request a licence in the hundred
dollar range. The developer of one of these apps has got close to
giving up and abandoning OAuth.

If there are other providers out there and a universal discovery method,
maybe the effort would be worthwhile ?


1. Look-up domain.com/.well-known/openid-configuration and get the
authorization endpoint

Hmm.
As A. Schulze says:

MS & Google and Keycloak both offer this URL:

https://login.microsoftonline.com/domain.com/.well-known/openid-configuration
https://accounts.google.com/.well-known/openid-configuration

I'll have to read https://openid.net/specs/openid-connect-discovery-1_0.html
to see why the literal domain.com in one but not the other
(and the other version doesn't work for MS or Google).

I don't see this openid-configuration in mutt, alpine or fetchmail.
Alpine has GMail, Outlook, Yandex and Yahoo hardcoded.


_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Reply via email to