Everybody has heard that OAuth is not an authentication protocol, but an authorization delegation protocol. That means it's designed to let you give access to something you own to other things or services. But, either the spec or everbody's implementation falls short when it comes to smart devices in your house.
My investigation into Google's OAuth began when trying to send an email via gmail and use their "modern" security standard of SASL XOAUTH2. You see, when you try to send a username and password to gmail to authorize - let's say - your security camera DVR to send an email alert, gmail now rejects that simple combination of email and password in favor of what it calls "modern security". Without any official documentation, I'm assuming this means OAuth2.
You can see a lot of forum posts complaining about how gmail no longer works after Google made this change to disallow a simple combination of email and password to authenticate people for sending via gmail's SMTP server. But, nobody ever posts a work around. I finally sat down to try to implement a real work around. The problem is, there is no work-around. There is no way to send email with OAuth2 authentication via gmail's SMTP.
Okay, there is, but only under very limited circumstances, like only from your smartphone or from a device that relies on a 3rd party, publically accessible Web service.
If you are trying to send email via Gmail SMTP from a smart devices in your home - like a Raspberry Pi - you cannot obtain the proper OAuth token (unless you plug a keyboard/mouse into the Pi and install desktop software on it so you can get the 127.0.0.1 redirect).
Google tries
Google extends the OAuth 2.0 standard to help limited input devices obtain OAuth 2.0 tokens, but it doesn't try at all to help smart devices access your account. Google adds a special redirect URI urn:ietf:wg:oauth:2.0:oob when requesting an auth code which puts the code in the title tag of the response. This allows you to programatically grab the auth code, or to give instructions to the user to copy and paste the code into your limited input device.
But it's not enough. Google only allows access to limited scopes (i.e. resources) when using that special redirect uri, and email is not one of them.
List of allowable scopes when using limited input devices:
- OpenID Connect, Google Sign-In
- Contacts API
- Cloud Print API
- Cloud Storage API
- Fitness REST API
- Calendar API
- Analytics Configuration and Reporting APIs
- Fusion Tables API
- YouTube Data and Live Streaming APIs
- Drive File APIs
Google also allows http://localhost as a redirect_uri, but why not just allow any reserved private IP? This decision restricts you to only authorizing things you directly interact with - like a smartphone - as opposed to a smart smoke alarm.
Now, to be clear, you can get an OAuth token for your smart smoke alarm, but it just cannot access Gmail SMTP.
Are IoT Devices Limited Input Devices?
But what is a "limited input devices"? We're talking TVs, Roku players, Fire sticks, Fitbits - devices that don't have a keyboard and mouse. But what about devices that have full web servers - such as Raspberry Pis - but which people rarely have physical input connected? These devices - which live on the network and which you only interact with via a network - are not a good match for OAuth 2.0 standards.
OAuth 2 seems to have been designed only to allow publically available Web sites to interact with each other. When it comes to a service that is not unique, and that lives on your local network, OAuth 2.0 implementations fail to allow redirect URIs that start with 10/192/172. The spec seems to only allow publically available Web site addresses. A smart devices that doesn't have its own .com will not be allowed to have authorization delegated to it.
Consequences of always needing public .com
A lot of people wonder, "What's the big deal? Just get a .com and get over it". But, there are a number of downsides to requiring a publically available .com (PADC) for every smart devices in your home.
Having a PADC as a requirment for interacting with the world of OAuth enabled services helps vendor lock-in. When the company managing that .com goes out of business, your devices becomes useless. Unless the devices is Open Source / Free Software, you probably cannot change the .com address that it relies on and point it at a service that you manage.
Requiring that you have a membership on a PADC spreads your exposure to hacks and makes your personal information more vulnerable to theft.
Requiring a PADC for every IoT device stifles innovation. It means that any IoT devices that you own is backed by a well-funded company that is making money off of your private information or that they are charging you a monthly fee. Baking in monthly fees for every devices in your future smart-home was not the promise of IoT and a connected smart home.
OAuth2.0 is great for allowing people to login with their Facebook account, but when it comes to delegating access to resources that I control to devices that I control, it falls short.
What's the workaround?
In the end, we just want our smart devices to alert us under certain conditions. Smart smoke alarms, smart security system, and smart water level sensors should send us a text, email, phone call, or chat message when exceptional conditions are detected.
So far, we cannot use the most popular free email, text and phone calls cost moneys, and chat programs from the post-AIM era are all walled gardens with no API.
If we want to use Gmail, we can change a setting under our account to use "less secure apps". This doesn't mean that the apps don't use SSL security, it just means that they simply authenticate with traditional username and password. Which also means that you can't revoke their access like you can with OAuth. But, this bypasses all the OAuth, so it's not really a workaround to get OAuth working, it's a workaround to send mail via Gmail SMTP.
If we're going to dump OAuth all together, there are any number of email providers we can use like: Mailjet, Mailgun, AuthSMTP.
I guess the work around is to just avoid OAuth on your Raspberry Pi projects. Until OAuth 3 comes out and allows you to delegate authorization to devices under your control, but which you aren't currently holding in your hand, OAuth 2.0 just doesn't offer enough.