I am using django allauth in a variety of application that i make and its awesome!
Right now, I am trying to develop a login process in two separate steps.
I have a client(mobile) social login with some provider(twitter, Facebook) and the client takes the oauth credentials and sends them back to the server.
That means, that i do not need to use the forms and the templates provided, since all that are handled just fine by the client already.
What i need, is to know what functions/views i need to call in order to avoid all the functions that need the request to work properly.
I hope that i explained in detail my issue.
Thank you in advance,
Michael.
Related
I'm new to OAuth and I would really appreciate if someone could give me a hand with my problem. I need to create a simple web application for track expenses, with some basic actions (user must be able to create an account and log in, list expenses, edit them, etc) with a REST API for each one, and the trick is that I need to be able to pass credentials to both the webpage and the API. So, after some research I've found some examples using Digest Authentication and HMAC Authentication but lot of posts also mentioned OAuth as an alternative approach, so my question is, given this scenario, would be proper to use OAuth? I mean, as far as I understand OAuth is suitable when you want to share resources with other application, which I'm not doing for this project; besides that, when you try to access the shared resource it appears a page requesting permission for the foreign application, would that page appear at some point in my application? (maybe after the login?)
Thanks in advance guys
In your current scenario it does not make sense to use OAuth. It's not what OAuth is designed for.
If your application ecosystem is going to have multiple webapps running on a single SSO (like google) then it is very helpful to have OAuth.
Suggestion: Decide based on your business/operation plan and implement accordingly.
Note: If you plan to have 10 apps in the span of the next 5 years but only have one app now it does not make sense to spend time to implement complex protocols like OAuth right now. Scale as you grow.
I'm currently trying to setup FOSOAuthServerBundle with my Symfony2 app.
Everything seems to be setup and functional, anyway I'm stuck after the installation.
What is the proper workflow with URLs to get the access_token ?
I tried /oauth/v2/auth, but sounds like I need to define a Client object first.
How to create/generate Client ? Clients are always supposed to be created manually ?
FOSOAuthServerBundle doc is great, but seems to skip all the usage workflow. Am I supposed to check the OAuth2 doc for this ?
Thanks !
In short, yes. You should be using the oAuth2 RFC to determine which workflow you want to use. In regards to client registration the RFC specifically states that the means through which a client registers is beyond the scope of the specification (https://www.rfc-editor.org/rfc/rfc6749#section-2).
With that being said I can give you some insight into how I did this. My application is a mobile phone application that connects to several services running on various servers. I'm also using the Resource Owner Password Credentials Grant.
The way I approached this was: when the application loads, the first thing it does is to check if it has an oAuth2 client id. If it doesn't, then it POSTS to a create client endpoint I've setted up with the meta-data I need. The endpoint validates the POST, creates the client and returns the client information. The application stores the client id and the process doesn't have to be repeated the next time.
Application loads;
Application checks for oAuth2 client id;
If there is one, the process ends;
If there isn't, it posts to http://www.example.com/client;
If we get a 200, store the oAuth2 client id.
I could have also created the oAuth2 client when the user created an account in the application, but I wanted to make the registration process as fast as possible. Creating the client would have added some extra waiting time to the process.
Check this: http://blog.logicexception.com/2012/04/securing-syfmony2-rest-service-wiith.html
It's quite simple to convert to Doctrine, whether you use it.
There's a command-line that does exactly what you need: create a Client!
I have setup FORM-authentication within web.xml (java-webcontainer) successfully.
I did not find a way to sent the username/password within the get-request of the restful-uri from my client when using FORM-Authentication. So I have to use BASIC-Authentication only for the restful-uri.
So I have this question:
How can I set up both form-based authentication and basic authentication?
Basic authentication should only be enabled for the restful-uri.
I was also facing a similar problem and I realized that if you are using Wildfly then its possible to configure multiple mechanism using web.xml:-
<auth-method>BASIC?silent=true,FORM</auth-method>
Using this silent basic authentication will be tried first, which is basic authentication that only takes effect if an Authorization header is present. If no such header is present then form authentication will be used instead.
Maybe its too late for a reply but I just updated this in case someone finds this useful :P
There were no responses here for a while, so I did a quick servlet refresher myself. Servlet specs indeed allow only one <login-config> element per web application, so there is no way to have an entry point with BASIC authetication for the REST API and another with FORM-based authentication for the UI. The only option is to build them as two independently deployable applications. To avoid code duplication, it might be a good idea just to let the UI application talk to the REST API the same way the third-party clients are supposed to.
I have a Facebook canvas app. I am using the JS SDK to authenticate the user on the browser-side and request various information via FB.api (e.g. name, friends, etc.).
I also want to persist some additional user information (not held on Facebook) to the database on my server by making an ajax call:
{ userFavouriteColour: "Red" }
To save this on the server and associate with the correct user, I need to know the Facebook uid and this presents a problem. How do I pass the uid from the client to the server.
Option 1: Add uid to the ajax request:
{ uid: "1234567890",
userFavouriteColour: "Red" }
This is obviously no good. It would be trivial for anyone to make an ajax request to my web service using someone else's Facebook Id and change their favourite colour.
Option 2: On the server, extract the uid from a cookie:
Is this even possible? I have read that Facebook sets a cookie containing the uid and access token but do I have access to this cookie on my domain? More importantly, can I securely extract the uid form the cookie or is this open to spoofing just like option 1.
Option 3: User server-side authentication on the server:
I could use the server-side authentication to validate the user identity on my server. But will this work if I am already using client-side authentication on the browser? Will I end up with two different access tokens? I would like to make FB.api requests from the browser so I need the access token on the client (not just on the server).
This must be a very common scenario so I think I'm missing something fundamental. I have read a lot of the Facebook documentation (various authentication flows, access tokens, signed_request, etc.) and many posts on SO, but I still don't understand how client-side authentication and server-side authentication play nicely together.
In short, I want to know the user's identity on the server but still make requests to the Facebook api from the client browser?
(I am using ASP.NET and the Facebook C# SDK on the server)
EDIT: Added bounty. I was hoping to get a more deifnitive, official recommendation on how to handle this situation, or even an example. As said, I have already read a lot of the official FB docs on authentication flows but I still can't find anything definitive on how client-side and server-side authentication work together.
Option 1:
The easiest way I can think of is to include the accessToken in JS and pass it with the ajax call.
Option 2:
Using the same as option 1, but instead of sending just the accessToken, send the signedRequest.
On the server side you can decode it using (TryParseSignedRequest method) which will give you the UserID :-)
Note: signedRequest is encrypted with the application Secret. you are the only one who should know it, so you are safe on that end.
Disclaimer:
I have no coding experience in C#, but a little search in google gave me this:
Facebook C# SDK for ASP.NET
Making AJAX Requests with the Facebook C# SDK
It's very simple actually.
When the user loads you app use the server side authentication, get the access token and load the user data by issuing an api request from the server.
On the server side you'll have everything you need and it's sandboxed.
When the page renders for the user, using the js sdk get the user authentication data, you should be able to use FB.getLoginStatus since the user already went through the server side authentication.
Now on the client side you also have an access token which you can use to get the user data from the graph api.
The two tokens will be different, and will also have different expiration, but that should not be a problem, both token should work properly as you'd expect them to.
Since both sides have their own token and a way to make requests to the api, there's no need to send any fb data between them.
So the 3rd option you mentioned, to me, sounds the best, and it's really simple to implement that too.
Edit
All facebook SDKs are just wrappers for http request since the entire fb api is made on http requests.
The SDKs just give you easy and shorter access to the data with out the need to build the url yourself (with all the different possible parameters), make the request and parse the response.
To be completely honest, I think that stop providing a way for the C# SDK to support server side authentication is a very bad decision.
What's the point in providing a SDK which does not implement the entire api?
The best answer to your question, from my experience, is to use both server and client side authentication, and since the C# SDK does not support it, my advice to you is to create your own SDK.
It's not complicated at all, I already implemented it for python and java (twice), and since you'll be developing it for your own needs it can be tailored for your exact needs, unlike a public SDK which should support all possible options.
2nd Edit
There's no need to create a completely new SDK, you can just "extend" the ones you're using and add the missing parts that you need, like sever side authentication support.
I don't know if it's language specific but using both server-side and client-side authentication does no harm.
You can work on option 2 but yes, that will be also vulnerable to spoofing.
Doing option 3, you will be having a single access token for that user session, so that would be the best choice according to me since you always have chance of spoofing when passing user information from client side.
I had exactly the same question recently. It's option 2. Check this post from the Facebook blog.
To be honest I am not enough of a hacker to know if you could spoof the UID in the cookie, but this seems to be the 'official' way to do it.
EDIT: to the other question under option 2, yes, I believe you have to access this cookie on your domain.
I am working with an app that is querying a JSON API on a server running Drupal. I used this tutorial and have changed the code a bit to work with my program, but every request just sends me to the not authorized page that the server generates. Any ideas why?
Why not use the drupal ios sdk? https://github.com/organizations/workhabitinc
I guess you haven't set the permissions in the Drupal service.
First go to permissions, and set the desired ones for the modules you're using (I guess you're using the default ones that are included within the services module).
Next, go to Site Building->Services, and authentication. Check if you have any authentication module set, and if so, add the methods that you're using to that key.
At our company we've made several apps which uses Drupal (but using XMLRPC instead of JSON). So feel free to ask everytime you need :)