I'm switching my application which previously used sharpbox (v1 api) to the new .net v2 api.
My app in the developers console of dropbox has no redirect uri set since v1 did not need it.
1) Is it true that in order to use v2 I need to use oauth2 and use a redirect uri.
2) What happens if I add a redirect uri to my existing app in the dev console. Will everyone using my app with the v1 code stop working? So what I'm asking is, does specifying that redirect uri create any changes to people who are using the old version of my app. Will it cease to function?
3) When I push out the new version using v2, I have no problems with forcing my users to re-authenticate to get new authorization tokens. Etc. Is that all that will be involved?
1) Dropbox API v2 does only support OAuth 2, so you will need to use OAuth 2 with it. However, you don't technically need to use a redirect URI. You can use the "code" flow without a redirect URI if that makes sense for your app. You can find more information in the documentation.
2) Registering a redirect URI on an app does not affect the existing API v1/OAuth 1 functionality.
3) The specifics of migrating an app will depend on the app itself. There are a few things to note though:
If your app uses the "file type" permission, you'll need to register an new app, as the file type permission is not supported on API v2.
If you already have OAuth 2 access tokens (API v1 supports both OAuth 1 and OAuth 2) you can use those directly on API v2 without re-authenticating your users (as long as your permission is supported, per the above).
If you only have OAuth 1 access tokens, you can upgrade those to OAuth 2 programmatically using either /1/oauth2/token_from_oauth1 or /2/auth/token/from_oauth1 .
Related
Facebook documentation states that
the App Secret or an App Access token should never be included in any
code that could be accessed by anyone other than a developer of the
app. This applies to all methods of code that are not secured like
client-side code (such as HTML or Javascript) or native apps (such as
iOS, Android or Windows desktop apps) that could be decompiled. https://developers.facebook.com/docs/facebook-login/security#appsecret
For this reason, if your 'App Type' under Advanced Settings in the App
Dashboard is set to Native/Desktop we assume that your native app
contains the App Secret or an App Access Token in the binary, and we
do not allow calls signed with an App Access Token to proceed. The API
will behave as though no access token was provided.
Therefore if you embed App Secret in your app and tell Facebook about it, it will simply stop working with OAuth (I have also tested this, when you check that option, Facebook stops validating the secret).
but Xamarin.Auth 1.3 (latest stable) requires clientSecret (in OAuth2Authenticator class clientSecret is the required parameter) and uses it to obtain Facebook access token when user successfully logs in.
So is it a bug, is there a workaround, or Xamarin.Auth is useless with Facebook for now?
OAuth2Authenticator contains multiple constructors and there is one that does not require ClientSecret:
public OAuth2Authenticator (string clientId, string scope, Uri authorizeUrl, Uri redirectUrl, GetUsernameAsyncFunc getUsernameAsync = null)
This one will allow OAuth2 Implicit flow and thus does not need a client secret to be stored within your application's code.
Ref: https://github.com/xamarin/Xamarin.Auth/blob/9c19d90e52994188def9e12e0bbc981a3943a752/src/Xamarin.Auth/OAuth2Authenticator.cs#L110
Let's not confuse things. This has nothing to do with Xamarin.Auth.
There are two major options for OAuth2:
Implicit flow
Authorization code flow
The implicit flow does not require a client secret. The implicit flow is typically used with mobile apps, since they cannot keep a secret (you could disassemble the app binary and find the secret). Same goes with Javascript or desktop apps. The only way to protect the secret is if it is stored on a server which cannot be accessed by third parties (=the users).
The authorization code flow uses the client secret as an additional protection, the secret identifies a specific party, like a server.
So what does Facebook state? They say, if you configure your app to be a native/desktop app in Facebook's dashboard, they assume (!) that you store the secret in the binary, because: where else would it go? As a consequence, the secret is no longer a real secret, hence the Facebook API acts as if the secret was not there.
Two solutions:
Either you configure your app as not native/desktop (I don't know which term Facebook uses, maybe "Server")
or you use the implicit flow which was designed for mobile clients.
And to answer your initial question: yes, Xamarin.Auth supports Facebook's OAuth2, because it is just like any other OAuth2.
I saw PayPal REST request documentation for java SDK at https://developer.paypal.com/docs/integration/direct/make-your-first-call/.
It requires a developer to register an application.
Now, using the calls mentioned by using the clientId and secret, i can receive an access token. This access token will belong to me and not any other user, so i will only be able to access my resources.
Now, If i make an application, and want to obtain access token of the user using my application, how can the SDK be used to achieve this workflow?
We recently created the instructions to use PayPal Java SDK. You can read them about it here: https://github.com/paypal/PayPal-Java-SDK/wiki/Making-First-Call
Using Java-SDK, you do not need to create access token separately. Instead you create an APIContext object, and pass your clientId, secret, and mode(sandbox/live). You pass this instance to all the API operations, and SDK will automatically call the oauth, and get the access token. This also improves performance by caching the access token and re-using it for later use. This only should reduce number of network calls to half.
I know this question has already been asked by someone else, but I didn't found the answers to my exact question.
I'm building a backend that provides its API written using Django REST Framework and integrates Facebook using Django Social Auth.
The frontend consumes the API using AngularJS.
I used a simple Token-based Authentication and everything went well, when somebody authenticated with Facebook I could retrieve the simple token (which never expired) from the DB and return it to the frontend, which will use it for subsequent calls to the API.
My problem now is that I want to publish my APIs and use oAuth2.
In order to do this I am using Django OAuth Toolkit.
If a user uses the native login there is no problem, because I use resource owner password based grant type (giving only client_id because the frontend is a JS app).
Now, if a user authenticates using Facebook there is a problem! I have no password to use!
This fact made me reconsider everything about authentication in my backend.
I thought this:
Is it sensed to make my "official" frontend app consume the APIs using oAuth2?
Isn't it better to use Token-based authentication (or Session-based, if you prefer) only for my frontend app and let third party apps consume APIs using oAuth2?
And, if I do like this, how can I tell my "official" app from other apps? Wouldn't it become a leak in security (for some reason, I don't know...)
My question is related to, but not exactly, this question.
I am currently working on a business directory Web site (similar to Yelp), in which businesses have their own pages. Let's call this app DIRECTORY_APP.
Businesses might want to have their latest Facebook status update shown on their pages hosted on our directory. Let's pretend we have a business named BIZ_1. The assumption is that those pages are public pages.
Apparently the Facebook Graph API can be used for this purpose. So I can send a request to Facebook to retrieve the latest status updates for BIZ_1:
https://graph.facebook.com/BIZ_1_PROFILE_ID/posts?
access_token=DIRECTORY_APP_ACCESS_TOKEN
&callback=callbackName
However, if I use this from the client side, our Web site's access token will be exposed to the public, so this is not a reasonable solution.
Now in the aforementioned question, Anatoly mentions that we can retrieve the access token by sending this request first:
https://graph.facebook.com/oauth/access_token?
client_id=YOUR_APP_ID&client_secret=YOUR_APP_SECRET
&grant_type=client_credentials
However if someone inspects the Network log, this will also expose our Web site's access token (is this correct or is this a different type of access token?). This solution also exposes our web site's app secret (is this safe?).
So to summarize, what's a safe way in which I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook?
I can retrieve the latest status update of a Web page from client-side without asking the browsing user to first log in to Facebook
You cant do that without login.
And I guess access token is not exposed.
Maybe the smart trick here is to use a social plugin. The Like Box will do what you want, without any issues. But, it's not greatly customizable. Even so, it's possible to get it looking nice on a page!
It also skips any login issues you mentioned.
I found the answer after some Googling. In short, the answer is no.
And here's an excerpt from Facebook:
Security Best Practices
App Secret and App Access Token
The App Secret is used in some of the Login flows to generate access tokens and the Secret itself is intended to secure usage of your App to only those that are trusted. The secret can be used to easily create an App Access Token which can make API requests on behalf of any user of the app, which makes it extremely important that an App Secret is not compromised.
Therefore the App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app. This applies to all methods of code that are not secured like client-side code (such as HTML or Javascript) or native apps (such as iOS, Android or Windows desktop apps) that could be decompiled.
We recommend that App Access Tokens should only be used directly from your app's servers in order to provide the best security. For native apps, we suggest that the app communicates with your own server and the server then makes the API requests to Facebook using the App Access Token. For this reason, if your 'App Type' under Advanced Settings in the App Dashboard is set to Native/Desktop we assume that your native app contains the App Secret or an App Access Token in the binary, and we do not allow calls signed with an App Access Token to proceed. The API will behave as though no access token was provided.
If your App Secret is compromised, you should reset it immediately in the Basic Settings of your App Dashboard.
We want to update our user profiles with information from LinkedIn (should the user choose to import this information). However, we want to this this authorization using Oauth2, but accordoing to LinkedIn's website only Ouath 1.0a is supported for their REST API: https://developer.linkedin.com/apis
Any way around this?
As LinkedIn is providing OAuth 2 access using their JavaScript API you could dive into their Javascript code and somehow get to the file, that has the OAuth 2 endpoints in it:
l.api = "https://api.linkedin.com/v1";
l.login = "https://www.linkedin.com/uas/connect/user-signin";
l.authorize = "https://www.linkedin.com/uas/oauth2/authorize?immediate=true";
[...]
l.logout = "https://www.linkedin.com/uas/connect/logout?oauth_token={OAUTH_TOKEN}&api_key={API_KEY}&callback={CALLBACK}";
l.userspace_renew = "https://www.linkedin.com/uas/js/authuserspace?v=0.0.2000-RC1.20001-1400&api_key={API_KEY}";
For requesting resources, probably the endpoints in their REST API documentation could be used.
However, note that it is probably forbidden by their terms of use to use these endpoints without their JS API and could result in your client being sanctionized. You could contact them and ask for permission.
I've created a Play 2.x client in Scala and Java which supports OAuth/CAS/OpenID/HTTP authentication and user profile retrieval : https://github.com/leleuj/play-pac4j.
For OAuth support, it's based on Scribe and supports LinkedIn, Facebook, Twitter, Google, Yahoo, DropBox, Github, Windows live, WordPress...