I'm testing Watson IoT using IBM Cloud.
I registered two device to IBM Cloud, and was issued each token value.
(A, B device and A, B token value)
So, I want to GET other device's token value, (from A device to B device)
Is it Possible ?
I think that it can not possible, because device token value can not check IBM Cloud Dashboard.
Is it right? I attached figure explained question. please give your advise.
Thanks.
enter image description here
Getting a device's token is not possible: when devices are registered, their tokens are salted and hashed. This means they cannot be recovered from Watson IoT Platform in any way - this is by secure design. (If you have lost your device's token, the only way to restore connectivity is to re-register the device to get a new token).
Hope this helps!
Related
Can we get credentials for the Google Calendar API on different devices?
We are using the Google Calendar API on the Raspberry Pi with the following steps as a reference.
https://developers.google.com/calendar/quickstart/python
We have generated the credentials by operating in the following steps
We chose TVs and Limited Input devices as the application type and then downloaded the JSON file.
Credentials > Create credentials > OAuth Client ID
https://console.developers.google.com/apis/credentials
Our Raspberry Pi does not have a keyboard and display.
We note the URL displayed in "Please visit this URL to authorize this application" via ssh.
We access the URL from the PC browser and note the authentication code after tying it to the calendar.
To "Enter the authorization code" we enter it.
It works as we expect.
But this is difficult for our customers.
Can we do this authentication using a PC or smartphone?
In that case, how do we move the token.pickle from the PC or smartphone to the Raspberry Pi?
Maybe we are thinking too hard.
If there is an easier way, please tell us about it.
We just want to use the Google Calendar API.
If you don't have a G-Suite account use SSH in order to send the tokens
Once you get the token.pickle you won't need to "visit" the URL to authorize the application. Anyway, a refresh token has its restrictions. A refresh token might stop working for one of these reasons:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
Use a service account instead (G-Suite account only)
The token.pickle is generated the first time. The quickstart you mentioned makes use of the user credentials. However if you want to use just one token along the devices and see a different calendar in every device I strongly recommend you to use a service account and enable the domain-wide delegation in order to impersonate the user's calendar.
To do so:
Create a service account
Enable the domain-wide delegation
Impersonate the user in order to see the desired calendar (using Python)
Reference
Refresh token expiration
Creating a service account
Can Google Sign-In be used on an iPhone app in conjunction with Touch ID? If so, how? I cannot find any examples of this being done or talked about online.
Apps can incorporate TouchID as a means to locally authenticate a user.
Basically, the TouchID system can be queried and will let you access items in a keychain or do a simple one-off authentication.
If you stored Google account credentials in a local keychain, you could use TouchID to unlock the local keychain item, and then pass that item to a Google service for Google's authentication.
The keychain item in question (a password) would have to be enter manually at least once by the user (and at that point, it is probably more straightforward to just request an reusable authentication token from Google).
TouchID is entirely a local system, no fingerprint data is ever exposed to third party developers or pushed to a network, so Google couldn't store a fingerprint in their servers and allow direct authentication against their services using TouchID.
Here's the framework reference for Local Authentication:
https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LocalAuthentication_Framework/index.html
The Local Authentication framework is best suited for either confirming a logged in user in an app where the user may be logged in between many sessions (such as for a purchase in a shopping app) or local authentication for local documents (such as for password protected note taking apps).
This is an architectural question related to the use of jwt.
When user logs in in my mobile app I generate a jwt. I do not know what strategy to follow when the same user logins on multiple mobile devices: to share the same jwt in all devices or to create a new jwt per device login?
Create a new token for each login.
apart from security issues, just not practical. To reuse tokens will need to store them on the server. This eliminates one of the advantages of JW : no need server space . What happens when a token is about to expire ? you issue a new JWT ? otherwise you will not be synchronized devices
I have a big database with devices token.
I guess a lot of my base are obsolete token.
How can I detect if a device token is obsolete?
Thank you.
For this exact reason, Apple provides a feed back service. You should set up a batch process or stored procedure in your database which periodically fetches invalid tokens and removes or mark as inactive in the database.
APNS : Feedback Service
I have a service with a Django-based RESTful API that is designed for iOS devices to access. I'd like to store some user data on the server -- non-sensitive things like favorites for example. I don't want to make a new user create an account, but I would like for the data to not be publicly available. The service also uses Apple's Push Notification Service (APNS). All traffic to and from the service uses TLS/SSL.
I am considering using a CFUUID generated by the device on first launch as a username and the token provided by APNS as a password. I would create a user account after I successfully register the device with APNS and update the password if the APNS token changes.
Is this a bad idea? Is there a better approach?
The approach I've decided to take is the above but without using the APNS token as a password. Instead, the CFUUID and token are sent as form-encoded data in the body of an HTTPS PUT request with a server-generated password to returned in the body of the response.