What exactly does the word "offline" mean with regard to the offline access granted by an OAuth server?
Does it mean that the resource server will return data about the user even when the user is logged out of the third-party application or when the user is logged out of the OAuth resource server such as Facebook or Google or Twitter?
Offline access is IMO a really bad name for it, and I think its a term only
Google uses its not in the RFC for OAuth as far as I remember.
What is Google offline access?
When you request offline access the Google Authentication server returns a
refresh token. Refresh tokens give your application the ability to
request data on behalf of the user when the user is not present and in front of
your application.
Example of an app needing offline access
Let's say I have a Super Awesome app that downloads your Google Analytics Data,
makes it into a nice PDF file and emails it to you every morning with your
stats. For this to work my application needs to have the ability to access
your Google Analytics data when you are not around, to give me permission to do
that. So Super Awesome app would request offline access and the
authentication server would return a refresh token. With that refresh token
Super awesome app can request a new access token whenever it wants and get your
Google Analytics data.
Example of an app not needing offline access
Let's try Less Awesome app that lets you upload files to Google Drive. Less
Awesome app doesn't need to access your Google drive account when you're not
around. It only needs to access it when you are online. So in theory it
wouldn't need offline access. But in practice it does, it still gets a refresh
token so that it won't have to ask you for permission again (this is where I
think the naming is incorrect).
Helpful quote from the OpenStack documentation:
If a refresh token is present in the authorization code exchange, then it
can be used to obtain new access tokens at any time. This is called
offline access, because the user does not have to be present at the browser
when the application obtains a new access token.
The truth about offline access
The thing is that in a lot of cases the authentication server will return the
refresh token to you no matter what: You don't have to actually ask for anything –
it gives it to you. Giving you the ability to access the users data when they
aren't around. Users don't know that you could access their data without them
being there. It's only the JavaScript library and I think the PHP library
that hide the refresh token from you, but it's there.
Example
By just posting (i.e. HTTP POST request):
https://accounts.google.com/o/oauth2/token?code={AuthCode}&
client_id={ClientId}.apps.googleusercontent.com&client_secret={ClientSecret}&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&grant_type=authorization_code
Here is the response:
{
"access_token": "ya29.1.AADtN_VSBMC2Ga2lhxsTKjVQ_ROco8VbD6h01aj4PcKHLm6qvHbNtn-_BIzXMw",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "1/J-3zPA8XR1o_cXebV9sDKn_f5MTqaFhKFxH-3PUPiJ4"
}
I now have offline access to this users data, and I never told them that I
would have it. More details be found in this short article: Google 3 legged
OAuth2 flow.
Useful reading
Using OAuth 2.0 for Web Server Applications
Understanding Refresh Tokens
By design the access tokens returned by the OAuth flow expire after a period of time (1 hour for Google access tokens), as a safety mechanism. This means that any application that wants to work with a user's data needs the user to have recently gone through the OAuth flow, aka be online. Requesting offline access provides the application a refresh token it can use to generate new access tokens, allowing it to access user data long after the data has gone through the OAuth flow, aka when they are offline.
Getting offline access is needed when your application continues to run when the user isn't present. For instance, if there is some nightly batch process, or if your application responds to external events like push notifications. However if you only access user data while the user is actively using your application then there is no need for offline access. Just send the user through the OAuth flow every time you need n access token, and if they've previously granted access to your application the authorization page will instantly close, making the process nearly invisible to the user.
For Google APIs, you can request offline access by including the parameter access_type=offline in the authorization URL you present to your users. Offline access, and hence refresh tokens, is requested automatically when using the Installed Application flow.
Related
I'm building an application that needs to have access to Google Drive and Google Sheets. I want the user to go to https://mydomain.appspot.com/authenticate to go through the Google login flow and authenticate themselves so that the backend receives access tokens for both Google Drive and Google Sheets.
After that I want the backend to be able to access Drive and Sheets without user interaction. For example, I would like a scheduled task to run every hour and retrieve some data from Drive and Sheets. I want the backend to use the token it received when the user authenticated themselves.
Is this possible? I really hope so. I have been looking here and I don't really find anything that can help me. https://developers.google.com/sheets/api/guides/authorizing
The backend is developed in Java and deployed on Google App Engine.
A long lived access token is actually called a refresh token. You will need to have your users authenticate your application then you will receive a refresh token. the refresh token can then be used to request a new access token from the Google authentication servers when ever you need.
Note: Do not get yourself side tracked with serviced accounts its not the same thing. You can run automated scripts using a refresh token gained from Oauth2, googles terminology is just a little confusing.
Check out the official google java client library it should handle most of it for you. Using OAuth 2.0 with the Google API Client Library for Java
You need to setup Offline Access as defined at:
https://developers.google.com/identity/protocols/OAuth2WebServer#offline
After a user grants offline access to the requested scopes, you can continue to use the API client to access Google APIs on the user's behalf when the user is offline. The client object will refresh the access token as needed.
Goal
Fetch a company's updates save them locally in a background task
Problem
This should be done as a backend service without any real user interaction. We could provide a user account to use, but the authentication is a problem: There is literally no one to answer the OAuth redirect and there is no public redirect URL to configure, since it's a background service.
Is there any way to access the API without having a redirect URL or a real user?
You can get an initial access token in a regular front end flow, for you as the app developer i.e yourself as the LinkedIn user. Once you've got that, you can store it in the backend and use it for 60 days to get access to the LinkedIn APIs.
After 60 days you need to refresh the token as documented in:
https://developer.linkedin.com/documents/handling-errors-invalid-tokens
Unfortunately LinkedIn does not (yet) support an autonomous refresh flow where your app can get a new access token by presenting a refresh token on a backchannel. So the developer will have to refresh the access token by a manual login every 2 months.
Well, it is still all HTTP and HTML, so in fact there is no real reason to show the OAuth dialog to a user, as long you can strip out the necessary parts in the HTML authentication dialog and send a valid response back to the server, using the username and password from the user (which you can obtain from him, or save it yourself in a config file if it is you).
Note that there might be a legal issue if LinkedIn demands you to actually show the dialog, beside that, there is no technical need.
It's funny but I can't find description of using HTTP requests to receive Google+ authentication code for offline access without iOS Google+ library.
Though example of it's integration is pretty straightforward, I don't want to add additional 20mb of weight to my iOS app.
I tried the approach described here
https://developers.google.com/accounts/docs/OAuth2WebServer#offline
but in case of server clientId I receive message abount incorrect redirect uri.
Could someone give me advice about it?
There are two approaches you could take that may/may not work for you.
Installed app flow with internally stored client secret
Web flow within a web view.
Installed app flow
You will must likely need to use the offline OAuth v2 / installed app flow which has redirect URI that has something like urn:ietf:wg:oauth:2.0:oob enabling you to redirect back to the browser, from there you can get a code to exchange for tokens.
In your case, I'm guessing you didn't create the right client type (installed application) which is preventing the *:oob redirect.
It's less secure to handle sign in in this way - if the user can extract the client secret from your app, they can do bad things like authorize a malicious 3P app with access to your application data.
Web signin flow
An alternative would be to use the web signin flow from within a WebView, something that Apple may reject your app for and which is also insecure.
What you would do is host the sign-in solution on your web server, use the JavaScript web signin flow to initiate sign in, request offline access, then exchange the resulting code for an access token and refresh token.
You would then store the refresh token / access token on the device and exchange it for an access token when you need access to the user data or exchange the refresh token server-side and pass the bearer token back to the iOS app when it needs access. This again is bad because it can expose other apps to user authorization credentials and could potentially allow a malicious 3P to access user data.
I can't recommend either approach. Is there a reason other than the app size impact that you can't use the library? I'll see if there is a good way to avoid the file size hit from the framework.
I have watched some videos on authenticating using oauth and have gotten the authentication part going but I have the following of questions.
Q1- Do access tokens expire?
Q2 -Do I have to make the user go through the whole user authentication process (with user authenticating the app again) once the twitter access token expires?
Q3-Is offline access to user's content possible once we have the access token
Ok so just to give some more context this is the scenario I have. Basically our mobile app is looking to integrate with twitter and there is a server side to it which needs to munch user's twitter feeds. And this is how we are thinking of doing it. Once the user authenticates our app using the mobile platform, we want to store this user access token in our server, poll his feeds at regular intervals and do some data munching on his feeds. For that we need
-Offline access to user's data
-Get a new access token without user's intervention if the previous one expires preferrably on the server side.
We don't want to have to go through user authenticating our app again.
The OAuth 2 spec is written in such a way that expired access tokens are a supported use case. Search for "expire" in https://www.rfc-editor.org/rfc/rfc6749 for example.
That said, the Twitter OAuth FAQ states:
We do not currently expire access tokens. Your access token will be invalid if a user explicitly rejects your application from their settings or if a Twitter admin suspends your application. If your application is suspended there will be a note on your application page saying that it has been suspended.
To clarify, Twitter's use of OAuth is much more basic than Facebook's or Google's. For details and further help, Google is your friend. ;-)
I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.
Where I'm confused if is it useful in a server web application? I don't want any user interaction.
But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.
What is the correct workflow for my case?
Storing the request token or access token in config file?
Or the easist way, using HTTP basic authentication?
Thanks
If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.
In this case there are 2 main factors to consider.
1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth.
2) Do you want to put in the extra effort to implement OAuth.
If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.
Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?
If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.