I have been studying the documentation for the Dropbox API but I couldn't find a way to directly access an account without going to the OAuth process. Is there a way to achieve that?
My final goal is to have a webpage with a list of files and folders from a specific Dropbox account (my own), which can be viewed and downloaded by anyone.
To access a user's Dropbox account via the API, your app will need to be authorized by the user. The Dropbox API currently requires that this authorization be done via the OAuth flow. You only need to perform this step once per user though, as you can store and reuse the access token for each user.
It sounds like you intend to use only one account though (your own), so you can just process this flow once manually yourself, and save and reuse the access token programmatically.
New answer, 9 years later, so probably new changes.
When you create an app in Dropbox, the settings page has a button to Generate Access Token. This will create a permanent token to access your own account without going through the oauth flow.
Related
I am building a website using .net. The plan is to use the strava api to get activity data of the user.
Currently the user will need to accept this strava prompt every time he reloads my site:
I got the auth flow working but my question is how to keep the user logged in. If I only store the tokens on my server I won't recognize the user on reload (or I have to use separate authentication). However if I store the tokens on the client the user will be able to make requests to the strava api on behalf on my application.
I tried to add custom jwt authentication to my server but don't like the complexity this is adding. I want to avoid it if possible.
Which of these is the standard way of doing it? Or is there a different strategy I am not seeing?
I am trying to get an access token using my dropbox username and password.
I don't want to go and generate it from there site, as mentioned in there help documents.
No, Dropbox API apps should use the OAuth app authorization flow to get an access token for the user, so that the app doesn't have to directly handle the user's credentials. You can find more information on this process here:
https://www.dropbox.com/developers/reference/oauthguide
The method of generating it on the App Console that you mentioned only works for the owner of the app, but the OAuth app authorization flow can be used for any account.
Note that while this does require manual user intervention, it generally only needs to be done once per user. Once the app has an access token for a user, it can store and re-use the token for future API calls without further manual user intervention.
Dropbox API access tokens don't expire by themselves, though they can be manually revoked by the user.
Everything I'm reading shows that in order for an application to use onedrive, it has to do the oauth2 thing to get credentials. But what if you're a batch process and don't have a web interface for your users.
Google's API has a special type of account called a service account where once you set it up, you can control access to everything from that one account, no need to interact with users. Does such a thing exist for onedrive?
App-only authentication doesn't require the user be prompted for credentials but it also isn't supported in 100% of scenarios. For example, the APIs need a user principle for creating special folders and resolving a user's personal site. Also, it is only supported for OneDrive for Business, not Consumer. Consumer always requires the user be prompted for initial authentication.
Another option would be to spin up a web service of some sort that handles initial user authentication, ie. a sign up page. With that, you can retrieve a refresh token for offline authentication and store it for the user. Every authentication from then on can be done using the refresh tokens, which doesn't require a user prompt.
I finally found this. It's the same basic idea as google's service account, but I think it's harder to use. But at least the concept is supported.
http://blogs.msdn.com/b/exchangedev/archive/2015/01/21/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
Will I be able to use the new REST File API from a service headlessly?
For example, I want to be able to create a service where the user gives consent once, and there-after the service may perform file operations (against sharepoint online) without explicit consent for months on end without intervention.
Such a thing is possible with other OAuth type REST apis (for instance the One Drive Rest API allows for it) by storing a refresh token and using it to get a new access token.
1) Is such a thing possible with these new APIs. The comment by "JTHAKE" in response to "Tdriver" here
http://blogs.office.com/2014/05/12/net-and-javascript-libraries-for-office-365-apis/ . seems to hint that what I want isn't possible but I'm not sure why not.
The new O365 rest APIs use the Common Consent framework in order to verify that the app has permission to use the APIs. This means that a user needs to first register an app in AAD & consent to the app's data use in the browser so that the app has the correct permissions. Once the app is consented to, completing the oauth flow headlessly will get you the right token to call the APIs from a service.
We are developing an SPA - full client base javascript application and need to authenticate our users to get access to the internals.
As I found from the search we can outsource our authentication mechanism and use Google accounts for that. I learned from this site
https://developers.google.com/accounts/docs/OAuth2Login -
How to deal with Google API and mechanism for authentication.
In the short word, we need:
send request to google url with params to ask user to allow SPA use their personal data
in case of success we get a token from Google
we may use this token to get access to API we were asked and work with it.
This is described well and I understand it and have some JS code to make it happen.
What I do not understand.
I have an application with it's private data. I want use user's e-mail as the login, or user id (doesn't matter how to call it) to access app's internals, such as user's created tasks, user's profile, etc. So, to display user's created tasks in my SPA I need query database with the user's e-mail.
I imagine the next scenario:
user click Login with Google button
we obtain an token - this means user was authenticated successfully
we persist user and his e-mail to work with SPA
when user click Logout we clear all access data
Where should I persist this data?
In case of Forms Authentication I understand that we pass login/password to server and if they match the database we create Forms Ticket and store it in cookie.
Is there any similar case with Google's auth? If I'll store user's email in cookie I think that's not very good from security reason. If I'll save a token - I'm not sure why I need it and how to use it in my SPA, I'm not using any Google API after authentication.
Do you have any example case how do we build our process in similar cases?
Thank you.
If all you need is the user's email address, then you would be better off using OpenID instead of OAuth. OAuth provides access to a user's account and services, scoped to a specific resource or set of resources. OpendID is designed just for logging into a third-party service. You can then extract the user's ID and email address from the OpenID login. Note: The ID will always be sent but the email address has to be explicitly requested during authentication.
Google also supports a hybrid OpenID+OAuth scheme that lets you piggyback OAuth requests on top of an OpenID login if there is some resource you need to authenticate to. Take a look at the authentication document to get an idea of how both protocols work and which is better for your scenario.
Once you have the email address returned, you probably shouldn't persist it in a cookie. The normally recommended way to handle it is to add it as a session parameter. That way only the session cookie is stored on the client, and the server can use it find the values it needs. This answer has a good explanation of the differences and when you want to use sessions versus cookies.