we´re planning to integrate Nuki in our App for giving our customers the posibillity to open their hotelrooms or rental house to their guests/customers.
Since we have our own UAC system in our app, we want to bind the Nuki access to the customer’s website. For this the website would have to register once via the OAuth2 interface. In order to allow the site access later on, our backend has to know the token and also has to renew it through the refresh token.
Now the question arises whether it is okay if our server always requests the token instead of the client?
Later it could happen that several requests for different accounts are sent at the same time from our backend server to Nuki Web. Is that ok?
Can anyone from the Nuki team only tell me if its allowed to save the AccessTokens in an own backend?
With OAuth you reqeust the token once and then reuse it, so I am not exactly sure about your question as this seems to describe the standard usecase.
Okay, maybe my explanation wasn’t quite clear.
Our own software (a CMS system) is already based on our own user account controlling. We use this to grant users rights to certain sub-pages.
We now want to integrate a site where a Master-Admin registers his Nuki-Web Account via OAuth2. Subsequently, the site itself will store the access token. This means that we only have to give the users access to the site via our UAC and they then have immediate access to the lock, as the site itself has the rights to control the Nuki lock.
You know what i mean?
Sorry, seems I missed your last reply:
If you share the token within your system it will be the same user to us. So I don’t think there will be any issue with that (as long as you handle tokens and refresh tokens following OAuth2 specification).
Thanks for the answer!
I sketched it again below.
For example: Our registration system -installed on a operators website- would like to grant access for a customer. In that case our system will grant access to a specific sub-site . This site has access rights to the Nuki Web (OAuth2) stored in the backend to control the locks stored in the account. The fact that the users granted by the registration system have rights to the sub-site means that they can control the locks.
We have now clarified that it is technically possible.
But is this also compliant with your data protection regulation and your general terms and conditions?
If you share the access token it is your part to do this securely and communicate this behaviour to the users and/or Smart Lock owners who share the access with you.
Though I can give you no legal advice here: We have no control over what you do with the shared access and so can and will not enforce restrictions on how you use it. From our view it is up to the Smart Lock owner with whom access is shared on what conditions.
Thanks for your answer!
For our project we need a client secret. As described here (https://developer.nuki.io/page/nuki-web-api-120/3/):
If you follow the “Code Flow” scheme you will need a client secret in order to receive an access token. Client secrets are issued only by Nuki. Please send an e-mail to firstname.lastname@example.org to get yours.
i requested it via email, but after 3 days i still have no answer.
How long does this take?
@tynie Sorry for the delay, we are currently switching this process to a smoother version where no emails need to be sent around. I will try to follow up with our server-admins to see to your request being answered soon. Feel free to PM me if you experience further delay.
Thank you for that fast reply! I will wait for the email answer