I am using InfusionSoft's API to save the contents of a form that is filled out on a website. The API uses OAuth, and from what I can tell there isn't a way to have a life-long session.
The way the OAuth appears to work is that it is designed for a user to login if their session has expired, just like logging into a website. This obviously isn't suitable for an API, but I'm sure this isn't an unusual requirement.
I have an initial token, but after that expires, what then? The only thing I can think of is to have a cron job that runs hourly to refresh the access token (there is a 'refreshAccessToken' method).
You need to store both the Access Token (short term - it is live for 24 hours) and the Refresh Token (long term).
You will only need to call the refreshAccessToken method at the start of each session. That method will return both a new Access Token and a new Refresh Token.
Use the new Access Token for the current "session" when making API requests. The Access Token will be valid for 24 hours (this changes from time to time).
Store the new Refresh Token and use it again for your next session.
Related
I'm kinda confused using Google API
I've a FORM on my website for booking events on my public calendar. Whenever a user books an event, I make a call to get an Access Token (using Client ID & Secret and Refresh Token), but using the same Refresh Token that I generated initially. For every new Access Token, I'm using the same Refresh Token. It's all working fine. But I don't understand the flow.
Do I need to generate a new Refresh Token on every call? What are some limitations of not doing so? Can I keep on generating Access Token with the same Refresh Token indefinitely? Thanks!
Refresh tokens are long lived they can expire if the user who's account was used to create it removes access. If its not used in the last six months google will also expire the refresh token. Here is one that is a bit tricky if you use the client id to request access of the user you get a refresh token if you do it again you get another refresh toke technically both refresh tokens work you can do this up to 50 times on the 51's time the first one will be expired. You can use a refresh token as many times as you want to get a new access token.
My question for you is who's google calendar are you writing to the users or some default one on your website? If this is a central Google calendar that you are writhing to then you should consider using a service account rather than Oauth2. I have an article on how service accounts are used if you are interested. Google Developer service accounts
I have a client application that use the oauth2 with authorization grant type resource owner password credential. I write a curl http request to obtain the access token when user provide her credential, but how to request another access token when the first one expired. I read that it's good to estimate the validity of the access token. I found this client library but I don't think it will solve my problem related to requesting a new access token once it expire or even when the refresh token expired too.
Can anyone point me to the right direction how to implement this or use a library for that purpose please?
Instead of checking token expiration for every resource request, you can handle token expiration error and perform a Refresh Token request to get a new access token.
oAuth server should normally mention invalid_grant in its response when access token is invalid, expired, or revoked. Refer here. You should check with your oAuth server what response it provides exactly when a token is expired.
Some libraries does include this feature but I do not find for the library you mentioned. I used Retrofit as java client and it has this. You might want to request this feature for the library you mentioned.
If a refresh token is expired, the oAuth authorization flow should start over again.
the OAuth2 token you receive will have the duration in it. Each token expires after a set amount of time and that information is sent back as part of the object you receive. So you can store it locally and reuse it until the expiration time passes.
Once it does expire you have two options :
Request another token
Refresh the existing token. A lot of the OAuth2 providers offer this functionality.
The only question is if the library you are using has that built in. If not maybe you can add it yourself.
Edit
if you want to store the token somewhere then Session will work. The Session does not expire when the user closes their browser bit when it hits the timeout expiration set on the host itself. To be fair if they reopen the app later, they will have to login again at which point you can request another token. If you decide to use the Refresh Token functionality then it makes sense to store that in the database itself and use it from there as this is a long term thing not something that is session based.
I have a PHP application usign LinkedIn API to show my company updates.
I know that the Access token has a duration of 60 days. And to refresh it I need to are connected to linkeIn and have a current Access token with less than 60 days old.
But my question is, in my application, users don't log in it, I use my own account to get the first access token and call API method with my Access Token.
How can I refresh my own access token to my web application works more than 60 days without get a new token manually? If I don't do anything but my app is still calling the API, the access token will be refreshed automatically?
Thanks a lot!
I am not sure but I think you have to manually login and update the 60 days token.
I have build a similar c#.net app where I save the token and exp.date in a file. I then cache the file for ever.
I cache the result from API for 5min. When cache expires and I make a new request to the API I also check the exp. date of the token.
When it is less then 3 days I send an email to admin to update the token by login in through my special login window where I save the 60 days access token.
LinkedIn's OAuth 2.0 documentation covers how to refresh your access tokens: https://developer.linkedin.com/docs/oauth2#refresh
Note that there is a requirement that the user is logged into linkedin.com in order to refresh their token - so if your app has no user interaction when you attempt to do the refresh, it won't work and the tokens will be expired by LinkedIn.
I created an app that also uses the Google Analytics API. However, I've got the following question:
When I'm asking for an Access Token I'm getting an access token that expires after 3600 seconds. I also got an refresh token that I can use to generate more access tokens later on.
Do I really need to use the refresh token to generate a working access token every hour or is there a way to have a user authenticate once and then always use the same code without going through the expiration trouble?
I want to have a cronjob, and while I know, it's easy to just use the refresh token to obtain a new one, I'm still asking if it's somehow possible to have an access token that lasts forever?
Otherwise I'll just refresh the token when needed.
There is a middle path: You can request the Access Token new on each call rather than use the refresh token.
That simplifies things so you can have just one function to get an Access Token and use it immediately within the cron job. This eliminates needing to store the refresh otken between cron executions.
I am making an OAuth 2.0 request and it is returning me JSON with refresh_token and access_token, why are there are 2 in OAuth2.0?
Which one is short lived?
What is the purpose of both?
I read this question on SO but that didn'e helped me much, Any help in this regard will be appreciated
Thanks
The access token is what you will use to authenticate your service requests. It generally contains details about the user or is directly mapped to the permissions about the user and the permissions that he has granted.
These tokens are short lived - something like one hour, the actual duration differs per provider.
The refresh tokens on the other hand are used to get a new access token when the one that you have expires. They have a much longer (sometime infinite, until explicitly revoked) lifetime.
Now, let's consider an end to end scenario. Let's say you create an app that does Facebook actions on a user's behalf - post on their timeline etc.
Your app redirects the user to log in to Facebook - you use Facebook SDK for this.
When the user successfully logs in and gives you the required permissions (post on timeline) you get an access token and a refresh token.
Your app can now hit the Facebook API to post on the user's timeline on his behalf with the access token. This token can be used for one hour (or whatever time the access token is valid)
Once the token is about to expire, you can hit a Facebook API to refresh the access token, as this one is about to expire. So, you call into the API with refresh + access tokens.
The API returns a new access token to you - you can use this now till it expires.
PS - This is not how it happens for Facebook actually. This was just a random example to explain how refresh and access tokens differ.
If this makes sense, go back to the question that you have linked. It has some really good answers. :)