Getting started with oAuth2

Mike Matthews - Omnis omnis at lineal.co.uk
Tue Oct 18 09:26:06 UTC 2022


Hello Philip & All Interested,

That is what I have so far, all good.  One point to note is the port number you have to set when you want to get the response back from MS.  This is $prefs.$serverport value.

My issue is with the $refresh system.  When the token is $refreshed, you will have to store the new value, but how do you share that new value, or store a value for every user, for every email combination?  This might be for shared email accounts, eg, sales at domain.co.uk<mailto:sales at domain.co.uk> etc.

Mike Matthews

Lineal Software Solutions
Commercial House, The Strand<x-apple-data-detectors://1/1> Barnstaple, Devon, EX31 1EU<x-apple-data-detectors://1/1>

omnis at lineal.co.uk<mailto:mike.matthews at lineal.co.uk>

www.lineal.co.uk<http://www.lineal.co.uk/>

www.sqlworks.co.uk<http://www.sqlworks.co/>



On 18 Oct 2022, at 11:27, Philip Tulett <philip.tulett at pdq-networks.com<mailto:philip.tulett at pdq-networks.com>> wrote:

Hi All,

As Doug has said, for sending emails, you do not need to use oAuth2, but for reading/receiving them, be it via POP3/IMAP you must use oAuth2 going forward.

I have stored the tokens/urls/timestamp etc in a separate DB Table and use Omnis's in-built function to encrypt/decrypt the oAuth2 buffer block before saving the record. One row in the table for each mailbox that is being accessed.

From a Microsoft point of view:-

There are two ways you can get your app registered:-
1), If your app is general purpose app that many customers are going to use, you as the developer can register the app in Azure as an enterprise app. You and your app will have to go through a validation/certification process. Your customers can then your app to their Azure AD authorised apps. In this case, the Client ID and Client Secret would be common across your customers.
2), Your customer registers your app in their Azure AD, and so generate a unique Client ID and Client Secret to their instance of your app. This is a far simpler process, but one that must be gone through for each customer instance.

Redirect URLs,
When registering an app, you must specify:-
Redirect URLs, ie where the tokens can be returned for your app. In the case of a local think client this would be http://localhost:[omnis_port]/api/__oauth2/omnis, in the case of a hosted app running on IIS this would be https://your_apps_domainname/cgi-bin/OS102/omnisrestisapi.dll/ws/[omnis_port]/api/__oauth2/omnis
The type of access it will require "API permissions". Such as "email", "IMAP.AccessAsUser.All", "offline_access", "SMTP.Send" etc.

The Authorize URL and Access Token URL are unique for each customer, but only in so much as the URLs contain the customers Tenant ID, other than that they are the same.

I have some screen shots of registering an app for IMAP/POP access but they won't go through the list, so contact me off-list if you would like them or more details.



Kind regards
Philip Tulett

-----Original Message-----
From: omnisdev-en <omnisdev-en-bounces at lists.omnis-dev.com<mailto:omnisdev-en-bounces at lists.omnis-dev.com>> On Behalf Of Mike Matthews - Omnis via omnisdev-en
Sent: 18 October 2022 07:02
To: OmnisDev List - English <omnisdev-en at lists.omnis-dev.com<mailto:omnisdev-en at lists.omnis-dev.com>>
Cc: Mike Matthews - Omnis <omnis at lineal.co.uk<mailto:omnis at lineal.co.uk>>
Subject: Re: Getting started with oAuth2

Hello Michael,

I have started with this as well.  As Kelly says, get your app registered.  My issue is how to store, and where tp store, the $refreshToken.

If you use your account from different computers, how do you keep the $tokens, otherwise you will have to sign in via MS webpage often.  Servers can’t do this, so they need silent connection, but I think there has been a solution somewhere for this.

If you use oAuth2 on two different comports to the same Exchange account, then you will have login twice I think.

Confusing, but working on it.

Mike Matthews

Lineal Software Solutions
Commercial House, The Strand<x-apple-data-detectors://1/1> Barnstaple, Devon, EX31 1EU<x-apple-data-detectors://1/1>

omnis at lineal.co.uk<mailto:omnis at lineal.co.uk><mailto:mike.matthews at lineal.co.uk>

https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.lineal.co.uk&c=E,1,73UZyp8nVjOVVc0WZ7FEimNokKODsYFjZZo-p6t4tIIh5nokKecBjwzsPW5yls0ViHHRy3z24oIBaKYte3qS-sDGrtprCAzhHfp2UUgrbNdAkciSLnacFg,,&typo=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.lineal.co.uk%2f&c=E,1,bM-kvDjCV-Sg3VJ8xuTX9as2_ZqmyNeqxCIAnaoqfyC3AlG717y-fYgbByFWj_So1N3fF33gCAiXyGExsHs4HrmAN5uTK0nR3DMeRnYg&typo=1>

https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.sqlworks.co.uk&c=E,1,ZY3OrMfkPWfgOp-JRA42aiAKr-ztwLq-z7sGNkrdN1LFUaHespCtxsPL5F6bXN7uGHFxC2e7oueClisCLmOagZyHL9QmV7sz5UBByn7RTA,,&typo=1<https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fwww.sqlworks.co%2f&c=E,1,u6-tj4D_9K_xnV4klWGNQQiYXAZy3hIcMwE-Tb4L6b6Rxe0bWmiStS5cEBjRUWQ779KmFAqK-zTateSg_ZX6lz_i5nDnzmTH0PIpXlY9-8mnsLQmb98Ww_cEjA,,&typo=1>



On 18 Oct 2022, at 07:45, Kelly Burgess <kellyb at montana.com<mailto:kellyb at montana.com>> wrote:

Are the Client ID and Client Secret something that I need to get one time from Microsoft for my application

Yes, for OAuth 2 to work, you need to register your application so that the token server will know who it's working with.  The result of a successful registration will be your Client ID (aka application id) and your Client Secret (app secret).  You keep these for the life of the app, and you'll send them along as part of each of your auth token requests.


Authorize URL and Access Token URL.

These two URLs will be unique to each service that requires OAuth2 (Microsoft, Google, Dropbox, etc. each have their own server URLs).  In general, you request authorization (using your client ID/secret) from the Authorize URL, and it will return an auth token, which you then send to the Access Token URL.  The access token server will normally return three items - an access token, a refresh token, and an expiration timestamp for the access token.  Until that time elapses, you use the access token to request service APIs.  After that time elapses, you use the refresh token to obtain a fresh access token along with a new refresh token and expiration timestamp.

Obtaining the original access token usually presents a web page for the user to log in and approve the use of resources.  Using the refresh token to get a new access token sidesteps the need to log in and approve access again.

Kelly


More information about the omnisdev-en mailing list