Overview

• User adds Mozilla WebThings Gateway skill to their Mycroft device through home.mycroft.ai
• User clicks the configure button on that skill in the Mycroft web interface
• User clicks the button to authorize with their local gateway in the skill's configuration
• Browser opens a popup of https://mozilla-iot.github.io/oauth-proxy/?client_id=mycroft[... lots more text]
• User inputs their gateway url into this page, gets directed to https://their-gateway.mozilla-iot.org/oauth/authorize?client_id=mycroft[... more text]
• User completes the OAuth flow on their gateway, choosing which things they want to share then clicking Allow
• Gateway sends a code to Mycroft
• Mycroft sends this code to the AWS-hosted skill token passthrough
• The STP sends the code to its corresponding gateway
• The gateway sends a token to Mycroft which is then associated with the skill
• User can now use the skill and say things like "Hey Mycroft, turn on the kitchen light"

Important tidbits

• The services we provide in this are https://mozilla-iot.github.io/oauth-proxy/, the skill token passthrough, and the tunneling service.
• The only thing associated with the skill is the token because the token encodes which gateway Mycroft should talk to
• The skill also enables users who opt out of the tunneling service to configure everything manually

Dark underbelly: the skill token passthrough

While Mycroft could write the necessary logic in their side of the OAuth flow to not require a proxy like the skill token passthrough, I view this as too much of a burden. The skill token passthrough is a simple lambda skill deployed on Amazon's API Gateway which just parses the authorization code JWT and sends it to the corresponding gateway.