Having that, it would facilitate integrating various Domoticz scripts and plugins to exchange data with various external sources and cloud services like Google, Yahoo, Twitter, Github, Microsoft, Facebook, Amazon, Uber, Spotify... well the list can be made very long. Without a Domoticz built in oAuth2 setup handler, developers must rely on making their own solutions for establishing the credentials and it will look different for every implementation and it won't help the end user as things tend to get quite complicated.
It would open up many doors for Domoticz to integrate with the outside world ...Google Identity Platform wrote: The list below quickly summarizes these steps:
- Your application identifies the permissions it needs.
- Your application redirects the user to Google along with the list of requested permissions.
- The user decides whether to grant the permissions to your application.
- Your application finds out what the user decided.
- If the user granted the requested permissions, your application retrieves tokens needed to make API requests on the user's behalf.
Authorization Code Grant
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
Code: Select all
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)