API Integration Manual for Daikin DKN Cloud Wi-Fi Adaptor
10
--form "grant_type=refresh_token" \
--form "client_id=CLIENT_ID" \
--form "client_secret=CLIENT_SECRET" \
--form "refresh_token=REFRESH TOKEN"
-
RESPONSE: This returns a JSON object, with the same properties as the previous request.
Example response:
{
"refresh_token": "vkVz6nVhtwb6cZgylCsAEev3eetcrRCG",
"token_type": "bearer",
"access_token": "3VOO9NScVG02ibR2ssrGAjIcnblRbG0I",
"expires_in": 7200
}
We can observe that the refresh token request is basically the same request as the previous
one, with the difference in the request body parameters: for requesting a refresh token, the
value of the
grant_type
property is now
refresh_token
, and the
code
property is substituted
for the
refresh_token
property.
Both the access token and the refresh token can have it’s
TTL (Time To Live)
parameter
configured. By default, the Open API issues access tokens of a lifetime of two hours, while the
refresh tokens never expire. This configuration is set up to avoid the need of doing the
authentication process all over again in case the refresh token expires. Also, when issuing a new
pair of access/refresh tokens with the refresh request, the old pair of tokens will be invalidated.
2.4 Oauth2 Best Practices
Before diving in the API itself, we will point out some best practices in order to implement a safe
OAuth2 client.
OAuth Client should avoid forwarding the user's browser to a URI obtained from a query
parameter since such a function could be utilized to exfiltrate Authorization Codes and Access
Tokens. This refers to the first step of the web interface flow, where the application redirects the
user-
agent to the DKN Cloud NA authorization URL. It’s recommended not to ask another
service for this URL, because the request could be intercepted by a malicious entity and return a
different authorization URL. This could lead to redirecting the user-agent to a fake website,
where the user would perform the authorization flow, leaving authorization codes and access
tokens exposed. The recommended way of dealing with this auhtorization URL is storing it in the
application’s backend database, assuring the integrity of the URL.
If there is a strong need for this kind of redirects, clients are advised to implement appropriate
countermeasures against open redirection, e.g., as described by the
and ensure that each Authorization Response is only accepted once.
One-time use CSRF tokens carried in the "OAuth state parameter", which are securely bound to
the User-agent, should be used for that purpose. This encourages the use of the state parameter
in the Authentication flow as a method for the application to identify that the authorization
process hasn’t been tampered. When you use state for CSRF mitigation on the redirection
endpoint, that means that within the state value there is a unique and non-guessable value
associated with each authentication request about to be initiated. It’s that unique and non-
guessable value that allows you to prevent the attack by confirming if the value coming from the
response matches the one you expect (the one you generated when initiating the request). The
state parameter is a string so you can encode any other information in it. The way this works is
that you send a random value when starting an authentication request and validate the received
value when processing the response.
