I have created a tool that allows me to do automatic social media marketing by posting to Twitter via API. I would now like to do that same thing and share the extended message/tweet to my personal FB profile as well as the FB page. I have figured out a way to post to FB using Koala, the only thing is that the token constantly expires. Is there a way where I can continuously be connected like I am with the Twitter API?
Any thoughts, ideas, or suggestions are appreciated.
Facebook has a long-lived access tokens:
User access tokens come in two forms: short-lived tokens and
long-lived tokens. Short-lived tokens usually have a lifetime of about
an hour or two, while long-lived tokens usually have a lifetime of
about 60 days.
As you can see, even user's long-lived token will expire eventually. So it's up to you to either build a small tool to notify you when a token is about to expire or not. But in all cases, this can be done with cURL pretty easily (I have no ruby-on-rails experience): https://developers.facebook.com/docs/facebook-login/access-tokens#extending
Start with a short-lived token generated on a client and ship it back to your server.
Use the user token, your app ID and app secret to make the following call from your server to Facebook's servers:
GET /oauth/access_token?
grant_type=fb_exchange_token&
client_id={app-id}&
client_secret={app-secret}&
fb_exchange_token={short-lived-token}
PLEASE NOTE: that page access tokens generated from a long-lived user access tokens will NOT expire, see: https://developers.facebook.com/docs/facebook-login/access-tokens#extendingpagetokens
To get a longer-lived page access token, exchange the User access
token for a long-lived one, as above, and then request the Page token.
The resulting page access token will not have any expiry time.
Related
I'm following this article to understand refesh tokens.
In my case I have to connect to REST api using grant_type=password, and I receive a token with a 5 minute lifespan. So every 5 minutes I have to issue a POST request passing client-id, username & password to get a new acces token.
The other option would be to issue a POST with a grant_type=refresh_token, without having to send the username & password. In my case I'm consuming an api, so passing the credentials doesn't involve any action from the final user. For me it's just to params more to send on the POST request.
In both cases, I have to issue a new post every 5 minutes.
Is that the only advantage (not needing to pass credentials again) of using the reresh token or is there any other thing I'm missing?
Background info
OAuth 2.0 Password Grant
The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.
OAuth 2.0 Refresh Token
The Refresh Token grant type is used by clients to exchange a refresh token for an access token when the access token has expired.
This allows clients to continue to have a valid access token without further interaction with the user.
Consider this.
Lets say that i add my login and password for my twitter account to your application and you then use that to request access from twitter to may account to post. Three months later i have forgotten i have set your awesome app up to do something on my twitter account and i change my password. Your system will break.
Now lets say i used Oauth2 to grant you access to my Google drive account, your awesome app can now do what ever it needs to do on my drive account. Now three months latter i have again forgotten i gave your awesome app access, I have the memory of a gold fish you see. I change my password. Nothing happens your awesome app still has access.
Now consider this, With oauth2 i can grant you access to only read from my google drive account not update it (scope). That and the system knows its not actually me preforming the actions.
With client login (login and password) most of the time it appears to the system that it is the actually owner of the account making the requests. You can also not limit access with client login for the most part you have full access.
note
yes i am ignoring the part about both tokens returned being the expiration time time. Thats because for all intensive purposes they are the same but that depends greatly on how the auth server you are using is set up. They could be set up to only be valid for an hour or a day. They may give you different access scopes, again this differs greatly from auth server to auth server.
I tried to add YouTube Video from the third party and After one day, I got the success in doing so. But While uploading a video the access token is required and in order to get that access token the user must be logged in. And the expiration time for that access token is 3600 seconds( 1 hr).
Now, There are some of my questions regarding this.
Is there anyway, by which I can refresh access token.
If some one has G Suite account, then Is there any special values for expiration time, or it remains the same?
As per the documentation, I can have maximum 50 tokens, So is there any alternative for it, So that I can get valid token after 50 requests.
To answer your question for number 1, you can check the documentation here.
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that
object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the
user to Google's OAuth 2.0 server. In that case, Google's
authorization server returns a refresh token when you exchange an
authorization code for an access token. Then, if the access token
expires (or at any other time), you can use a refresh token to obtain
a new access token.
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
About the G Suite account, it was stated 24 Hours in the documentation. Note:
In this SO post answer, the function of Access Token and Refresh Token was discussed.
I am not sure if there are ways to alter the limits because of security reasons.
To clearly differentiate these two tokens and avoid getting mixed up,
here are their functions given in The OAuth 2.0 Authorization
Framework:
Access Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted
by the resource server.
Refresh Tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server
and are used to obtain a new access token when the current access
token becomes invalid or expires, or to obtain additional access
tokens with identical or narrower scope.
I read the documentation in the Youtube developers website it does not talk about any validity.
Does the OAuth 2.0 standards define any validity period or is the authorization token valid till the user revokes it manually ?
The OAuth spec defines that the token should expire shortly after its granted, so will it expire after I get the
access and refresh tokens ?
And can I use this access token for all future API requests or do I need to get a new token periodically ?
I'm assuming you are talking about the authorization code, you're mixing the terms a bit here.
From the OAuth 2.0 draft:
The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.
After using it once for getting the access token, you can not use it again. You also don't need to retrieve an authorization code periodically. You do this only when you have no access token for a user, but want to request his data.
Your access token some time expires. You know when by either looking at the expires_in value that got send with it, or by doing a request to the API and getting an access token expired error back. Then you can use the refresh token to get a new access token without the user being involved.
Very useful step-by-step guide about how to get access and fresh tokens and save them for future use using YouTube OAuth API v3.
PHP server-side YouTube V3 OAuth API video upload guide.
The good thing is, you do not need to worry about the expiry of the tokens, as the script in this guide checks, saves, and updates the token in a txt file for future access.
{"access_token":"XXXXXXXXX","token_type":"Bearer", "expires_in":3600, "refresh_token":"XXXXXXX", "created":000000}
We use at http://presentationtube.com and it works fine with thousands of users.
I am just getting started working with Google API and OAuth2. When the client authorizes my app I am given a "refresh token" and a short lived "access token". Now every time the access token expires, I can POST my refresh token to Google and they will give me a new access token.
My question is what is the purpose of the access token expiring? Why can't there just be a long lasting access token instead of the refresh token?
Also, does the refresh token expire?
See Using OAuth 2.0 to Access Google APIs for more info on Google OAuth2 workflow.
This is very much implementation specific, but the general idea is to allow providers to issue short term access tokens with long term refresh tokens. Why?
Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token.
Large scale deployment don't want to perform a database lookup every API call, so instead they issue self-encoded access token which can be verified by decryption. However, this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed.
The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.
A couple of scenarios might help illustrate the purpose of access and refresh tokens and the engineering trade-offs in designing an oauth2 (or any other auth) system:
Web app scenario
In the web app scenario you have a couple of options:
if you have your own session management, store both the access_token and refresh_token against your session id in session state on your session state service. When a page is requested by the user that requires you to access the resource use the access_token and if the access_token has expired use the refresh_token to get the new one.
Let's imagine that someone manages to hijack your session. The only thing that is possible is to request your pages.
if you don't have session management, put the access_token in a cookie and use that as a session. Then, whenever the user requests pages from your web server send up the access_token. Your app server could refresh the access_token if need be.
Comparing 1 and 2:
In 1, access_token and refresh_token only travel over the wire on the way between the authorzation server (google in your case) and your app server. This would be done on a secure channel. A hacker could hijack the session but they would only be able to interact with your web app. In 2, the hacker could take the access_token away and form their own requests to the resources that the user has granted access to. Even if the hacker gets a hold of the access_token they will only have a short window in which they can access the resources.
Either way the refresh_token and clientid/secret are only known to the server making it impossible from the web browser to obtain long term access.
Let's imagine you are implementing oauth2 and set a long timeout on the access token:
In 1) There's not much difference here between a short and long access token since it's hidden in the app server. In 2) someone could get the access_token in the browser and then use it to directly access the user's resources for a long time.
Mobile scenario
On the mobile, there are a couple of scenarios that I know of:
Store clientid/secret on the device and have the device orchestrate obtaining access to the user's resources.
Use a backend app server to hold the clientid/secret and have it do the orchestration. Use the access_token as a kind of session key and pass it between the client and the app server.
Comparing 1 and 2
In 1) Once you have clientid/secret on the device they aren't secret any more. Anyone can decompile and then start acting as though they are you, with the permission of the user of course. The access_token and refresh_token are also in memory and could be accessed on a compromised device which means someone could act as your app without the user giving their credentials. In this scenario the length of the access_token makes no difference to the hackability since refresh_token is in the same place as access_token. In 2) the clientid/secret nor the refresh token are compromised. Here the length of the access_token expiry determines how long a hacker could access the users resources, should they get hold of it.
Expiry lengths
Here it depends upon what you're securing with your auth system as to how long your access_token expiry should be. If it's something particularly valuable to the user it should be short. Something less valuable, it can be longer.
Some people like google don't expire the refresh_token. Some like stackflow do. The decision on the expiry is a trade-off between user ease and security. The length of the refresh token is related to the user return length, i.e. set the refresh to how often the user returns to your app. If the refresh token doesn't expire the only way they are revoked is with an explicit revoke. Normally, a log on wouldn't revoke.
Hope that rather length post is useful.
In addition to the other responses:
Once obtained, Access Tokens are typically sent along with every request from Clients to protected Resource Servers. This induce a risk for access token stealing and replay (assuming of course that access tokens are of type "Bearer" (as defined in the initial RFC6750).
Examples of those risks, in real life:
Resource Servers generally are distributed application servers and typically have lower security levels compared to Authorization Servers (lower SSL/TLS config, less hardening, etc.). Authorization Servers on the other hand are usually considered as critical Security infrastructure and are subject to more severe hardening.
Access Tokens may show up in HTTP traces, logs, etc. that are collected legitimately for diagnostic purposes on the Resource Servers or clients. Those traces can be exchanged over public or semi-public places (bug tracers, service-desk, etc.).
Backend RS applications can be outsourced to more or less trustworthy third-parties.
The Refresh Token, on the other hand, is typically transmitted only twice over the wires, and always between the client and the Authorization Server: once when obtained by client, and once when used by client during refresh (effectively "expiring" the previous refresh token). This is a drastically limited opportunity for interception and replay.
Last thought, Refresh Tokens offer very little protection, if any, against compromised clients.
It is essentially a security measure. If your app is compromised, the attacker will only have access to the short-lived access token and no way to generate a new one.
Refresh tokens also expire but they are supposed to live much longer than the access token.
I've written a little about this because I was pondering the reasoning myself today.
https://blog.mukunda.com/cat/2023/refreshing-access-tokens.txt
Essentially, I think the main security boost is only there if the refresh token does not remain the same over its lifetime.
Let's say someone steals your tokens from your browser cookies because they had access to your device temporarily.
If they use the refresh token, and the refresh token changes, then you have feedback – you are logged out. That can seem rightfully suspicious to careful users who can then take action and revoke all tokens.
If the refresh token doesn't update upon each use, then it is harder to notice that someone has access in tandem. (Chances are, if does update, then it might update from your device automatically before the attacker can even get to use it.)
If the refresh token does not get updated each time you use it, then I don't see any boost in security from the strategy, since it will be right next to the access token and client secrets.
So, why access tokens? It is so you can check that your credentials are valid regularly.
Do refresh tokens expire? Yes, but usually after a few months if you have "remember me" ticked. There's no expiration time in the spec, so you just go until it fails. Services that require longer unmonitored sessions might have secret credentials so they can refresh their refresh token.
Update:
I also glossed through the OAuth 2.0 specification and see the same reasoning, though it emphasizes that the invalid authentication feedback can be caught on the server side. That is a great point – the server can automate revoking the token if it is compromised.
If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.
I'm developing a Twitter application on OAuth and I want to provide the ability to post updates in the future.
The basic plan is to run a script every hour and find any updates which need to be posted, and then authenticate the appropriate user and use the statuses/update API call.
However, I don't know how I can use OAuth for this. I obviously don't want to store their username and password - that defeats the object of using OAuth in the first instance.
If, though, that is the only option, then how can I not store a plaintext copy of their password but still authenticate them?
With OAuth you only need user credentials initially to get the oauth token. After you have the oauth token, you use the oauth token in place of those credentials. The only issue in subsequent calls under OAuth is any TTL (time-to-live) associated with the token on the service-side. Twitter does not apparently expire tokens, so once you have a valid token you should be able to continue to make calls on behalf of the user. The only times you would need to get credentials from the user are (1) in the initial stages of running the application, or (2) if the user's session becomes invalid for some reason (changed password, user-directed invalidation of the session, etc.).
See the OAuth spec for more details.
Note that should you intend to use the same user token between invocations of your application, you should be prepared to encrypt the token and store it securely. Should someone capture your consumer key and secret, along with the user token, the identity of the user can be compromised.