Note on Facebook’s secure cookie format
In their new secure cookie format, Facebook provides an OAuth code, which Koala
automatically exchanges for an access token. Because this involves
a call to Facebook’s
servers, you should consider storing the user’s access token in their
session and only
calling get_user_info_from_cookies when necessary (access_token not present, you discover
it’s expired, etc.). Otherwise, you’ll be calling out to Facebook
each time the user loads a
page, slowing down your site. (As we figure out best practices for this, we’ll update this
wiki.)
Let me get this straight: even if I use the Javascript SDK to parse
the cookies I still need to do a server-to-server call to facebook? Doesn't this make the whole java script SDK for user authentication kind of useless? I always need to check the cookies (so I won't have a stale access token) thus calling facebook every time?
What this quote is talking about is lightening the load on Ruby by not re-validating the OAuth token with a key exchange btwn Ruby and FB every call.
So, you can save the token in session/db/your own cookie/etc. or you can have FB's JS SDK revalidate it and pass it to you as part of your request.
Related
I am building an API for my rails app. Through that API I will log users in and allow them to interact with their data.
On top of that users authentication, I will also like to make sure only my iOS app has access to the API, and eventually my own web app.
I want to make sure no one else will be using the API, so on top of the user authentication, I will like to protect my API with a token for each of my apps.
How do you usually solve this problem? Would I have to pass that token over on each call in order to authenticate that the call is coming from a valid client and identify which client it is (web vs iOS).
I will very much appreciate any pointers or if you know of an article explaining how to deal with this.
As you are already using jwt's to authenticate your user, why not just use the functionality of jwt to include additional information in the token, in this instance some form of hashed string that you can verify server side if it is a valid "client id".
On each request you could refresh the string.
Kind of dual authentication in each request. the user and the client.
So I have an application that currently logs the user using linkedin. We are using several oauth services to register and login the user into our application, however we do need to validate the authentication in our own server to make sure any requests to our API are valid.
Currently the linkedIn SDK is not functional in our application due to minimum API level restrictions, so we are using a different library (LinkedIn-J), I am able to retrieve the user access token and secret, I cannot find any reference as to validate them in the server.
How can we go around to making this work? Is it even possible to achieve such a thing?
Thank you very much.
LinkedIn does not have a token validation endpoint. Your best bet is to make a simple non-destructive call like https://api.linkedin.com/v1/people/~ and watch the response to determine whether the token is still valid.
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.
I'm currently developing my own service with its own app. The service has a backend JSON API that the app uses to communicate.
Now, since an iOS app does not have sessions or cookies, I was wondering how I would go about creating a user authentication/login for my app. Should I simply locally encrypt the password/username and then, for every action (such as posting a new entry), send the user/password with the request (which seems unsafe), use a token-based system (app receives a token from the service when authenticating, saves it locally - encrypted - and then sends it with the request), or something else? Should I try to implement OAuth for my service?
I'm using the CodeIgniter Rest API for the backend.
Thanks!
My preference includes both. I normally use oauth2 with a bearer token setup (if I remember correctly). I ask for a username/email + password, encrypt the password client-side and send it to the server via Basic Auth in return for an access token which I can send on all consecutive calls. That way I can always revoke access to the backend by invalidating the access token. Oauth2 is much easier to implement than Oauth 1.0a and by following the specification, it is easy to open up your api for 3rd party apps later.
The Oauth2 access token can be send as a GET parameter, but lately I start to think sending it as a header might be preferable, to distinguish better the meta parameters like an access token and data parameters like it's or a model's actual data.
I am trying to do a Twitter connection using a webview in the excellent Appcelerator Titanium. I know there is a great library from David R out, but I do not want to use a popup and I feel that I need more control over the flow.
My question is: During the authentication flow I need to get an oauth_token which (in my knowledge) is a combination of the consumer key and other values. How can I do this? How can I generate this token so that I can continue the process?
I am of course using Javascript.
Thankful for all input!
It is a multi-step process based on the OAuth 1.0 specs, you can find the details at <http://oauth.net/core/1.0/>
Before doing anything, you will need to register an application with Twitter and they will provide you with a Twitter API Key and a Consumer Token (Key and Secret).
For the next steps, I highly recommend you use OAuthConsumer or some other library, but the steps include generating a proper request to get a "Request Token" from <https://api.twitter.com/oauth/request_token>
then using this Request Token, you need to request the user to authorize your application using <https://api.twitter.com/oauth/authorize?oauth_token=REQUESTTOKENKEY>.
This last step provided you with a Request Verifier allowing your application to make the final request for a permanent Access Token from <https://api.twitter.com/oauth/access_token>.
When you receive the Access Token, you should store a copy somewhere so the user does not have to re-authenticate your application every time (unless that's what you desire). This Access Token does not expire until the user specifically removes the access rights of your application from his Twitter profile. Make sure to store the entire Access Token, meaning storing both the Key and the Secret.
Good luck!