I'm currently developing an application that essentially perform background fetch of reports from a salesforce account and save them into a db, the flow goes more or less like this:
-A user logs-in in my app.
-Selects add salesforce connection.
-He is presented with a form to provide consumer key (client_id in some docs) and consumer_secret as shown in Develop-Remote Access (in a salesforce account).
-Then the app initiates web server flow as described here and the salesforce login form is presented so user can authorize my app, app get access token, then request refresh token.
-Once the app goes through all this process it obtaines the refresh token to update the access token once it expires so it can make subsequent call to API functions. Once the refresh token is get, the user doesn't have to go through all the flow, just log-in to my app and see his data updated.
This refresh token is obtained to perform updates of reports even when the user is not logged into the system.
However, before doing all that user has to go to the Develop - Remote Access section to get consumer and secret and provide it to the app. Average user don't get this easily, is there any way to simplify this? Any experience on how to simplify the process, am I looking at the wrong flow? Btw I'm working with java.
Thanks.
You can create one remote access setting in your own developer org and then re-use that, it's automatically shared, you don't need to have your customers create their own ones.
Related
Imagine you've to implement following user story:
"User should be able to publish message on social media(facebook/twitter/etc) using simple web form and one-click button[without need to login in fb/twitter/etc]."
In general, authentication in social networks is based on OAuth 2.0. Facebook distinguish three types of access tokens:
User access token
App access token
Page access token
I've tried first option with facebook4j, and it's working - however, we are supposed to supply token each time, we want to use it. I've found long-lived tokens, but their validity is also limited - 60 days.
Generating app access tokens is very simple, but I haven't succeed in publishing any post. From facebook docs:
App access tokens can also be used to publish content to Facebook on
behalf of a person who has granted an open graph publishing permission
to your application.
Page access tokens - I haven't tried. Is it possible to publish message on fb/twitter simultaneously, without login, of course, to predefined destination(fb wall)? If so, please provide me with any working example :)
Thanks in advance
I'm creating an ecomerce app for a local store and they use Quickbooks Online. I can see the Quickbooks Online API requires a "Connect to Quickbooks" button where the user then logs in, but that's not what I'm looking for. What I'm looking for is something when they look at the products page, the app queries (or sends a REST/SOAP call) and gets back product data for my store. Our customers will have no idea that we're using quickbooks online, and definitely won't have a login. The flow would be like:
Customer clicks Products
ProductsAction will execute a service call to QuickBooks to get the products we sell (select * from products)
ProductsAction will return Success passing in the list of products to the page to be rendered.
mycompany/Products renders the items returned from QuickBooks Online.
Is there any possible way to do this? Everything I've read requires O'Auth authentication (meaning the user would have to login to QBO).
Feel free to ask any questions an thanks in advance!
I can see the Quickbooks Online API requires a "Connect to Quickbooks" button where the user then logs in, but that's not what I'm looking for.
Yes, it is.
You only have to log in ONCE. Exactly ONCE, and then you never, ever have to log in ever again. So, your QuickBooks admin logs in ONCE using the "Connect to QuickBooks" button, and then NEVER LOGS IN AGAIN.
Instead, you store the OAuth tokens, and use the stored tokens to do you queries from there on out.
What I'm looking for is something when they look at the products page, the app queries (or sends a REST/SOAP call) and gets back product data for my store.
This is all perfectly do-able. The reason you can't do it right now is because you're not storing the OAuth tokens like you should be.
Our customers will have no idea that we're using quickbooks online, and definitely won't have a login.
They don't need to have any idea about this. Store the OAuth tokens after you connect ONCE, and then everything can be unattended, no login, you just query away whenever you want to.
Is there any possible way to do this?
Yes!
Everything I've read requires O'Auth authentication (meaning the user would have to login to QBO).
The QuickBooks admin logs in ONCE and then never again. Store the OAuth tokens after that one and only login, and then use those to do all of your queries in the future.
This is how OAuth works for every single application that uses OAuth on the entire planet. Log in and authenticate once, store the tokens you get for future queries.
...
...
Did I mention you should be storing the OAuth tokens that you get back after that one single time your QuickBooks admin logs in? :-P
Yes, you can do this:
Create an account on https://developer.intuit.com using your accounts QBO login.
Make an app
Grab OAuth creds from the API Explorer.
See my tutorial for help on the first two steps: http://minimul.com/integrating-rails-and-quickbooks-online-via-the-version-3-api-part-1.html
You still need OAuth creds but since you only desire to interact with your company/personal QBO account you don't need to do anything formal, just get the OAuth credentials somehow. Once you have the credentials you can start building your integration code.
I'm building an application that needs to query and fetch the Facebook public feed every hour or so. I only need read access to the public feed. I can make the query using the Access Token generated on the Graph Explorer page but that token expires after an hour or so. I know there is a way to get a 60 days token and use that, but that requires updating the token every 60 days.
Whats the correct way of doing this? All the material I have found so far assumes a front end application that needs a user's login authentication.
You can't get offline access token for facebook (unlike google).
You can get access token for 60 days, and when user asks for page that requires authentication, redirect him to login page.
In playframework you can do this with securesocial module (and i am sure there is social module for whatever server you choose to use).
Alternatively, you can extend the short-lived access token.
I am unsure of the technical details of how to do this, only that it is possible.
Maybe this link can help you:
Facebook full permission AccessToken alternative to Offline access token
I am making an Android app which will fetch data from my API.
First thing my app will do is to let users signin using their credentials.
My question is does my API need to handle sessions? or should I authenticate the user for every request?
Will the native android app hold the user credentials on the device and send them along for every request after signing in?
I am using Retrofit. How would I send user credentials after they have signed in?
This will be a good time to take a deep dive and read into OAuth. Your use case seems to match perfectly. There are 2 main steps you will need: Authentication and Authorization. I have briefly explained them here: Authentication of a resource in Dropwizard. You can ignore the DropWizard part, the REST concept remains the same. The short version of the description could be like this: A user installs your app on the phone. They authenticate ONCE using their username and password (POST request to your REST over SSL). Your service authenticates the user and return back with a "refresh_token" and an "access_token" which the app saves on its side while you map and save the access_token/refresh_token on service side with the user. With every subsequent request your app is going ot send the "access_token" as a part of "Authentication" header which you, on the serverside, will parse and check if the access_token is still alive (assuming that access_token expires) and if it is alive, then complete the authorization/authentication process. If by any chance, the access token has expired, 401 will be returned back to your app. The app will have to then use "refresh_token" to get a new access_token and once approved with a new access_token (which again ofcourse is mapped on server side to the user's identity) all the subsequent calls will use the new access_token, till the time it expires. This is a simplistic version of OAuth and does not follow the specs to the letter. It's a very basic authentication/authorization flow to get you started. I hope this helps!
We use the username-password grant to connect our JS client to our REST server. In a way the token returned by oauth/token is our session, as it allows access to the backend for a limited time.
We would like to refresh that session/token every time we make a request to the backend using the token.
I know there is this refresh token issued by the server and I could use it to refresh my token after it has expired.
The thing is: I don't want to make it the client responsiblity to catch token expired exception and re-authenticate or schedule a refresh prior to token expiration. I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session. (I also wouldn't like it to issue a refresh request with every "data" request, though I think I remember reading, a refresh token is only valid once..?!)
Is there a way to do that in spring security or will I have to build some custom implementation of the token store or whatever part I choose?
Since I can't really find an answer (hence the post) I'm thinking: Maybe it is not wise to do this, though I can't think why. If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..
EDIT
In response to Luke Taylor's answer I'll clearify our use case.
We have a REST server that holds application data like persons. but also provides access to our content management and allows clients to post to facebook. It encapsulates application logic and data storage
We have a fully fledged client application already in place that has its own security layer and justs accesses the data on our REST server via client credentials flow. Who can do what is decided on the client side
We have several medium and small applications like a contact app on facebook that access the data on the REST server also using client credentials
We are now developing a client application using only javascript that will access the REST layer to do all the stuff the big client application does but also needs to provide a means to authenticate individual users and allow multi tenancy. Therefore this new client application uses the username-password grant to authenticate and method level security to authorize the users
So we have a REST server that needs to provide complete access to our trusted application that does its own security stuff and that same server needs to provide access for users of our new multi tenancy javascript client application. In production we will have several REST servers each with its own database but the core will always be the same, so in theory one server should be able to handle all.
I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session
This doesn't really make sense (in an OAuth2 context). The access token is issued by the authorization server, which decides how long it is valid for. It is "used" at a resource server, which may be completely separate from the authorization server, so there is no facility in OAuth2 to connect usage with the lifetime of the token. It would in theory be possible to hack something together which made this work, but it sounds like a bad idea.
If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..
The access token is used repeatedly and sent by the client to servers other than the authorization server. The refresh token is retained by the client and only sent back to the authorization server. A client also has to authenticate to successfully use a refresh token, so the client id and secret would also have to be compromised.
It's not really clear from your question why you are using OAuth2. You should probably expand your question to clarify this. If there is only one client and a REST server, why not just use something like BASIC auth over HTTPS?
Also, is the client a browser-based app? If so, the username/password grant isn't really suitable for use in an untrusted client.