Open hobinjk opened 7 years ago
Basically clone https://github.com/settings/applications/new
I don't think I understand this well enough to know how it should fit into the rest of the UI design for OAuth, can you explain it in a bit more depth?
How did you get to that form on GitHub? Where is it linked from?
Also, this reads as though we need to hard code a list of supported third party services into the gateway at build time. Is that really what this means?
It's linked from https://github.com/settings/developers > "New OAuth App". In return for that information GitHub gives you a Client Id and Client Secret to use in speaking the OAuth protocol. The flow I have in mind is that a developer wants to create a new service to use with the Gateway and doesn't want to use the old copy the JWT method. They can go to this form, input something like name "Local Test Service" callback url "192.168.0.105" or "coolservice.local" and get presented with a client id and client secret. They can then use this information to set up an oauth client on coolservice.local without having to manually edit src/models/oauthclients.ts. The "homepage url" and "application description" of the GitHub form aren't really necessary in this local-only context.
The current status with OAuth is that we hard code a list in src/models/oauthclients.ts. This is for services that we want all Gateways to support, like IFTTT or Amazon Echo. We could instead create an external OAuth verification service that each Gateway makes requests to during the OAuth flow. This would allow adding globally trusted third parties without an OTA update but we'd also have to design and build this service from scratch. While creating this kind of service isn't impossible, hard-coding globally trusted clients seemed like a better approach to me.
There's also a theoretical way to do decentralized OAuth verification by throwing crypto primitives at it
The Local Token Service takes care of most of the desire to make OAuth easier. There is some space for people to want to create their own local OAuth clients but this is mostly unnecessary for now
The Gateway should be bundled with a known list of third parties. The Gateway should only support OAuth flows with unknown third parties if put into debug mode or manually trusted (not sure about how to best do this as users will probably treat it like a certificate warning)