Offering a new sample for OAuth 2.0 process with Microsoft Outlook in cloud

[kpishere]

@slaff and @mikee47

As mentioned previously, here is a sample application that I'm offering to add to the project.

It uses an ESP8266 with an old VFD 20-character display to display the next Outlook meeting you're to be at. I put it at my work desk as popups on display are just not good enough (especially in MS Windows!).

Lots of hurdles to go through these days in world of OAuth and SSL/TLS all over the place. It should make a nice platform for others in other device to service pairings.

https://github.com/kpishere/vfdOutlookEvents.git

[mikee47]

@kpishere Thank you for this. It's an interesting sample, and as you mention in the README does raise some issues with the framework (memory, mDNS).

I've got the sample running under the Host emulator (so we can forget about the memory issues for now) but still need to familiarise myself with setting up OAuth2 for outlook.

Note: mDNS is available under LWIP2, just needs a coule of tweaks to pull it in. Something to handle via #1713 probably; all the ZeroConfig stuff really needs a separate Component to handle all the detail, so we don't need to keep messing about with this low-level C code. I'll probably throw a draft PR together for that since you've kind of started the ball rolling with this PR :-)

Can you perhaps help me understand a little better how OAuth2 works in this context? For example, does the device need to be directly visible on the internet with it's own IP address, or can it still sit behind a NAT firewall?

[mikee47]

@kpishere I've pushed some commits to your repo. as a review, hopefully helpful.

[kpishere]

@mikee47 OAuth in a nutshell :

But first, no it does not have to be exposed to internet.

You have the resource (Outlook in this case), the browser, the authority, then the client device. At the authority, you define the resource, set a secret and client id, and set local callback urls for login. Callback url can be http://localhost.., but all others are https. The tennant id identifies the authority/account space for an organization, the client id is generated for any client. A secret is also generated for the client. The device must have url of authority's login, tenant id, client id, secret, and url to resource. From web browser, you make request to device to get authorization, the device makes get request to authority, the response is saved, browser receives redirect to load this downloaded login page. Login page communicates with authority directly (cross site scripting must be allowed in browser) the response contains local redirect back to device (this is where mdns is handy) and the code value which is saved. With the code value, a request for a token can be made to authority from device. the returned token is good for 1h and there is a refresh token which is good for days. With token in header, device can make application api requests to resource. when token is no good, request new token with refresh token and continue with app.

Typically this can all be done in memory but as you see in this implamentation, lots of baby steps with saving to spifs and timer calls so device can 'rest'.

No more logins are needed as long as refresh token does not expire (30 days i hear but this can be any time, that is up to authority policy) and account permissions do not change.