The Android Management API WebToken resource can only be created so I guess it is designed to expire at some time. What is the exact behavior as I did not find this information in the documentation?
Yes, the web tokens generated using enterprises.webTokens.create that identifies the enterprise. The lifetime of the token is limited to only a few 4 hours, so even though there is no API to expire, the token will only be active for a few hours.
Related
I've been using the Google API to update one of my Chrome plugins on a weekly basis. This has now happened 3 or 4 times now: The refresh token I acquire will work properly for up to two weeks (only being used once per week), then the third week, returning an error saying that my token has been expired or revoked.
Given that I'm the only user with access to these tokens, I know that there isn't any spamming, and I know that nobody would be authorized to revoke the tokens on my end.
Please advise. Thanks!
There are serval reasons why an access token can expire.
the user revoked your access.
depending upon which scope you are using if the user changes their password it can revoke all out standing refresh tokens (mostly gmail I think)
If your application is still in testing phase refresh tokens only last for two weeks you will need to move your application to production and go though the verification process. (this appears to have been a stealth change i can find no information on it)
you can have a max of 50 outstanding refresh tokens for a users account, if the user is logging in multiple times and you get a new refresh token each time make sure you are always using the newest.
Your application should always be set to request access of the user again in the event that the refresh token has expired.
I have recently worked with Google Ads API and Shopping Content API and experienced detailed behaviour of API authentication mechanics.
What i can tell for sure regarding authentication is the the following:
An Access-Token always have a life time of 60min. and then expires
An refresh-Token makes it easier to obtain a new Access-Token, since
no additional verification is needed
The lifetime of a Refresh-Token varies
it can be a 6 month or more (when the related application publishing status is released)
or just 1 week (when the related application publishing status is testing)
You can find detailed information regarding Token Expiration on the Google API Documentation https://developers.google.com/identity/protocols/oauth2#expiration
Also information regarding publishing status of your API application Token has expired or revoked - Google Ads
We are using the following method to generate a token to be used to make calls to the Yammer data export and REST apis. https://developer.yammer.com/introduction/
The token looks to be working for the most part, but it will expire ever 2 weeks for some Yammer instances. However, according to the documentation, I thought that the tokens generated in this way are not supposed to expire.
Are there any specific reason why tokens would be expiring every 2 weeks? I know that the user is not being deleted or deactivated.
Thanks!
The access tokens are long lived and I have being using mine for about 4 months now. You want to double check to ensure that the user did not revoke the app's access from the "My Applications" page.
I have started building a C# asp.net website that will have the ability to post directly into Yammer (we have Yammer Enterprise). I have used the REST api to create a post and have also been able to create in impersonation token to post on behalf of other users. It works fine, but reading the documentation, the tokens seem to have an indefinite lifetime. Forgive me is this is a stupid question, but is there an expectation that as a developer, I should store the token locally (eg in a SQL table) and reuse local version for future API calls?
If the API call fails, then I assume I regenerate the token and re-store for future use?
Thanks
Andy
Yes, these tokens don't expire until an account is suspended or deleted in Yammer, or the user manually revokes the app. Until that changes you need to be very careful with handling these tokens. Applying encryption, permissions, and other techniques to secure your app is the best way to protect them.
You might also consider storing the time when the token was acquired or last used. Then delete the token after a period if it hasn't been used. That will protect the user.
In your UI make it clear what your app does with Yammer so that users authorizing it are aware of what they are opting into.
We are developing multiple apps for our client which all can be used using same credentials(credentials of there company portal).
So we want to implement something like single sign on, such that user need not to login each app.
I have already gone through these links
http://msdn.microsoft.com/en-us/library/live/hh826544.aspx
http://stackoverflow.com/questions/5598411/single-sign-on-choices-to-use-with-windows-phone-7
Here is what i need exactly:
step 1.) When user login to one app(say App1), the portal will return a token, ineed to store this token somewhere, such that only authorized apps can access this.
Step 2.) when any other app(of same group) launches it will check on the location for the token and if token exists, it will not demand for credentials.
Step.3) When user logs out from any app, it will remove the token from shared location.
We have already implemented this in IOS using keychain(possibly wrong term as i am not ios developer).This keychain provides a common space for the apps signed with same certificate.
As per my knowledge uptill windows phone 7.5 there is no possibility. Does windows Phone 8 has something for this.
If not i am open to any kind of suggestions to serve the purpose.
P.S. : Security is our major concern, So when you suggest please let us know you think there could be any security concers though hack or phone loss.
Thanks a lot..
I hope to be corrected but this won't work. Apps are isolated and can't share things like data packets and such.
i am not a windows app guy.
but a trick can work.
caution:
following can raise security concerns if API token expiration time limit is not properly considered.
use firesharp / any XMPP service (suitable for windows client) to send api tokens to other devices like notification message.
handle the notification in such a way that token is not displayed.
and also remember, there is no such think as log out in API authorization.
you will have to restrict access with token expiration time limit.
I am working on a Windows Phone app that utilizes the Facebook API. To do that I need the user to login and authorize my app, so that I can get an access_token. I've already done that, it works fine.
The question: how to keep using the Facebook API on the next launch of the app without having the user to log in again?
What I do: When the user logs in I save the access_token and the expiration time. Later, I can use the access_token when making API calls. This is all fine.
The problem: with offline_access not working anymore, the access tokens I get are valid for 60 days. This means that after 60 days they will stop working. Can I do something to renew those tokens without asking the user to login again?
My research:
I read the documentation, but it seems to mention only Android and iOS. While I assume it would be similar for Windows Phone, I am not able to find out what to do. The Facebook libraries for those other platforms have something like:
facebook.extendAccessTokenIfNeeded(this, null);
I was not able to find similar method for Windows Phone. While I read somewhere that this does not actually work for Android, it hints that there must be a way to do it.
I read about the new endpoint allowing renewing of access tokens, but it seems to only be able to extend short-lived tokens to long-lived. For me it is a bit unclear from the documentation here(Section 4):
https://developers.facebook.com/roadmap/offline-access-removal/
Any help is appreciated, thanks.
Follow the Offine Access Removal Guide on the link you provided. It has the API Call you can use to get a long-lived Access Token for the user - this is the replacement of offline_access.
Specifically, see Scenario 4.
In theory, Windows Mobile should fall under Exception 2 / 3. See if the Windows Mobile SDK has an option to access the access_token in a similar way to iOS and Android.