EMail using OAUTH2

[Heather Kirk]

Hello, all.

The application I manage has the ability to send EMail using

SMTP, by specifying SMTP server, account information, port number,

and authentication method.

As of this morning, my users can no longer send EMail on their

Outlook/Hotmail/Live EMail accounts.

A quick search revealed that Microsoft has released a change that

requires the use of OAUTH2 as the authentication method, for third party

EMail senders.

I likely should know how to do this, but I do not....and I have

clients asking me what I'm going to do about it, and how fast

can I do it.

Without the luxury of time, I am turning here to see if anyone

has done this.  I am using the OcEM EMail framework.

And...I have no need to RECEIVE EMail....only SEND it.

I will keep looking, in the meantime...but any help would be

greatly appreciated!!!

Thanks in advance.....

Heather Kirk

[Marcus Wagner]

Dear Heather,

read this under the assumption that you provide Smalltalk code which has to send a mail to somebody.

That means instead of opening a socket, sending a login and then the mail, you must provide now something which handles the different purposes and partners.

For short, I do not know OcEM. In what follows, I am not assuming anything about OcEM.

I also do not know the current rules enforced by Microsoft, being in the role of the ressource owner.

OAUTH2 is a protocol to add security. This means a change of the protocol and administrative preparations.

Instead of sending user/password to access the mail server and send mail, OAUTH2 establishes now roles and duties:

A client now must obtain a fresh access token which has to be provided in any request of this session - instead of having gained access initially and then sending further requests in the same session (without further access checks). 

This access token also expires, e.g. in a lengthy session you have to be prepared to be able to reconnect by requiring a new access token.

Sending a mail reduces the session to perform a single request (although, in the worst case, the fresh access token might already be expired before its single use, hance even then you have to be able to reconnect).

So instead of sending a login/password expecting an acknowledge and then sending the mail you have to establish a session (might also be the same, sending a user/password), gain an access token and then to sending a request containing the access token and the mail to be sent.

This separation of authorization (addressing the authorization server) from sending requests (turning to the ressource server) requires you also to handle different target addresses to be used in the protocol (although the end point is fixed after being initally established).

Out of scope of OAUTH2, this may also place additional burden on you customers: depending on their required level of security the resource owner will provide adequate means. This is involved additional administration out of our scope (in this case a matter of the relation between customers and Microsoft).

So customers have (indirect) influence to design the complexity of obtaining the access token. As I said, I do not know current rules imposed by Microsoft here. May be that they do not make use of a client token in authentification. 

The following is out of an experience with a required client token, where the login was secured by requiring the client to provide a client token, when sending a login. In such scenarios it is up to the resource owner to administrating this token. This allows e.g. to retract access in the case of loss/theft of a client machine.

Out of personal experience in establishing OAUTH2 (not for mail but in data exchange using SOAP) I recommend to reserve significant time to establish such a framework. This also stems from the involved encryption.

Also be prepared to provide tools to trace and check the protocols in testing.

Kind regards

Marcus

[Heather Kirk]

Thank you for the detailed response, Marcus.

This aligns with my own knowledge and experience with OAUTH in general.

My concern for this specific situation, is that having to obtain a fresh token, means all of the

automated EMail functionality will be rendered unusable, since the user will be required to allow

the access token each time.

As usual, Microsoft has minimal information to support developers, so I cannot speak to their implementation

for their EMail service, but....well....OUATH requires a user to acknowledge permission, so as to obtain that token.

So, I think it's pretty likely that they will need to be directly involved in any sending of EMail.

Again....thank you for the reply!

Best Regards,

Heather

[Heather Kirk]

I wasn't thinking too far ahead when I sent the first post.

The OcEm framework is a solid, but dated framework.

It has worked perfectly for us over the years, and only simple

enhancements were ever needed (which we provided in Goodies).

It seems, however, it is finally time to shed the comfy blanket,

and embrace the newer, more powerful framework provided by

the VAST team, in the form of the SstSsl framework.

A quick look has shown that there is an OAuth2Authentication option.

So, clearly, before anything else, it seems as though my first task is to

rewrite my own EMail framework to switch from the OcEm stuff to

SstSsl.

It is very likely long overdue....but I wasn't expected to have to do this

while a set of our users have lost the ability to send EMails to their patients,

and are eager for a solution!

The only saving grace is that the vast (no pun intended) majority of our

users, are using GMail, or some other service provider, and are unaffected.

Sigh....thanks, Microsoft!

Heather