What I am planning to do:
Authenticate user using FB/Google on the client side(on the phone)
Pass the authentication confirmation to the server
Create another token to use for future communication with app
So I would write a "login" app that will create this token and that's it.
My problem:
Since all the data is mapped to UserID, how do I map the token to the user ID?
Do I write a Django middleware that does this conversion?
Do I store current_token in the User object
Do I store a map of token -> userId and use this when generating data that templates will use?
or
Do I store the user_id locally and pass it along with the token?
What I am planning to do:
Authenticate user using FB/Google on the client side(on the phone)
Pass the authentication confirmation to the server
Create another token to use for future communication with app
You never, ever, do user validation on the client side.
Social validation also happens through the server-side using the API of the openID provider (in this case, Google/Facebook).
What you are going to do is to use one of these 4 found here:
https://hackerluddite.wordpress.com/2011/05/17/review-of-4-django-social-auth-apps/
Test each of them out, see which 1 fits your needs.
What you aren't going to do is to build out your own social registration tool.
The biggest reason being that is has already been built and tested for you, so you don't need to reinvent the wheel, unless you are doing so for the sake of learning.
Security is also important, and you can consider your own solution to be less secure than a tested version.
Related
I am creating an Android app that will be using a Django backend, along with the Django Rest Framework. I have been reading the OAuth2 documentation, but am still struggling to understand a few key points about its authentication.
These are my main questions/things I'm struggling with:
In OAuth2, I am given the oppurtunity to create 'apps'. Would the 'app' in this case be specific to my Android app (and presumably in the future I would create a different one for a potential iOS app?).
Will all users of the (Android) app be using the same token, or is each user granted an individualized token?
I am using the Volley library for Android to deal with networking. How do I go about getting the Android app to 'store' the needed credentials? Would I be storing the token, id, and secret, or just the token?
If it is worth noting, I do not plan on adding social media logins (Facebook, Google, etc) I will just have login be with a username and password.
I'm sorry if these questions seem a bit elementary, this is my first experience will authentication of any sort.
Thank you
I'll be using the word "app" to mean two different things:
app, to indicate Oauth2 app, which you'll create to register your mobile app(s)
app, to indicate mobile app.
Answer 1:
An app is basically a way of registering a client (in this case, your mobile app) with the resource server (in this case, you Django backend). You can go either ways, creating two separate apps or a single app for your Android and iOS apps. Unless you are not planning to give users of one app some more privileges or features, I don't see benefit in creating two separate apps.
Answer 2:
Each user is granted a different access token.
Answer 3:
You'll have to store client_id and client_secret in some secure way on your mobile app(s). Because that's what will help you gain an access token for a user, in first place. You'll also store access token after obtaining it, because it will be needed in making authenticated HTTP requests.
For more information on Oauth2 Protocol in general, you can read this answer, and Oauth2 Protocol RFC.
Let's say I have this application developed for Android which needs to use a Facebook (or Twitter or Google or all of them) based authentication so it can access this private API I've developed with nodejs' Express for example (could be any other platform too). I've read this answer here that gave me a hint on how to associate my authentication model with my user model (and another one here that made me realize those two parts are different), Facebook authenticates and I use some information they provide to create an "identity" for this user, but what exactly is this information that will create a link between the user and the identity? no abstract terms please, do I need to use and send either the access token or the Facebook user id? or would I just send the access token and let the server get the user id?
Regarding new requests after this user has been authenticated, I've read about API keys of some sort, which are basically some random strings that I should add to my identities (or users? this part confuses me) entities, and they should be securely stored in the mobile device as a mechanism to authenticate further requests, but how do I securely get this random string to the device in the first place? am I misunderstanding the way API keys work? are Facebook authentication and API keys mutually exclusive? if so, what would I use for further requests just using a provider for my authentication? it seems illogical to pass the access code in every request, even more so passing the user id.
The focus of this question is for me model a solid strategy for managing this authentication-user-identity behavior, would love any insights on how has this been done before since the material I've found in SO and the web has been very lacking, often referring just to server side implementations or just authentication answers, not addressing the issue of further requests.
The Facebook/User ID is there to identify the (returning) User. Keep in mind that you only get an "App Scoped ID", not the "real" ID - it will be unique in the App, but different in another one. See changelog: https://developers.facebook.com/docs/apps/changelog
Access Tokens are there to make calls to the Graph API. There are 3 different Tokens (App Token, User Token, Page Token), you can read more about them in those articles:
https://developers.facebook.com/docs/facebook-login/access-tokens/
http://www.devils-heaven.com/facebook-access-tokens/
You can store Access Tokens for later, but in most cases you don´t need to store them - only if you need to access the API while the User is not using your App.
In general, App Tokens can be used to request public stuff and to change App settings. User Tokens can be used to request (or post) User stuff and Page Tokens can be used to request insights of a Facebook Page and other things.
If you want to deal with Access Tokens on your own, make sure to activate appsecret_proof in the settings. I suggest reading this article about securing API calls: https://developers.facebook.com/docs/graph-api/securing-requests
I've recently done some OAuth authentications on Android apps (or iOS), but I now have a problem.
When this OAuth authentication needs to be stored in a remote server to perform login request. Which is the best way to do this?
Should I send access token from this oauth provider, and then get otherr access_token just for my app?
Or should it be done in a different way?
Thanks!
Well, there's no general answer but I'll try to explain.
2 basic flows I can think of :
1) If yo don't want that your app directly asks for a username/password, you can use Facebook/Twitter login.
2) Ask the user for a username/password directly and implement your own OAuth service with your server, then use an iOS OAuth library to communicate with it. Your service will need to perform user/pass authentication at some stage.
You can either generate a random UID (user identification) on the client and use that to communicate to the server. Or you can just pass the username/password, let the server generate a UID and from there on communicate using that UID in the request headers.
Hope this help
I am writing a Google App Engine application along with a CLI client, an Android client and a Javascript client. The purpose of this application is to allow one to control an Android phone on which the Android client is installed, by using either the CLI or the Javascript client.
Authentication plays a crucial role as a bug might allow a malicious user to control others' phones.
The Android client is written and works. It authenticates the user using this method. Basically, this give me a so-called SACSID token I can store in a cookie. When this cookie is set App Engine recognizes my user. The server application can then call the UserService to get a User on which to call getUserId(). getUserId() returns me an opaque string that identifies my user. So far so good.
Now I am writing the JS and CLI clients.
Because the CLI client has no reliable way of displaying a CAPTCHA or opening a browser, I suppose that it needs to use the Device API ("Client login" is not an option). This API requires using OAuth 2 for authentication. Also, I want the JS client to access the user's contacts, which also seems to indicates that OAuth 2 would be suitable.
If my user authenticates using OAuth 2, will I be hable to somehow transform this Google OAuth 2 token into the same opaque String that I get when the Android client connects ? If not, can I modifiy my Android Application so that it uses OAuth instead of a Sacsid token ?
To be more specific, I see three things that would solve my problem :
A way of getting an OAuth 2 token from the Account Manager
A way of exchanging the OAuth 2 token for a SACSID token
A way of getting the same opaque UserID both with the SACSID token and the OAuth2, but only if I can have both authentication system on the same application.
Something that seems similar to the third possible solution is to get the user's email address from both OAuth and the SACSID token, and to use that as the user ID. This however looks a bit clumsy to me :
Every time I receive an OAuth 2 request, I would need to call Google APIs to retrieve the user's email address (or build my own system of tokens which seems insecure and introduces many other difficulties).
The email address of a given user can change, making me lose the association between the user and his previous data.
Use End Points instead:
https://developers.google.com/appengine/docs/java/endpoints/
They use oauth2, they are easy to implement and have support for android IOS and Web.
I am trying to get Authorization for Google Buzz,Contacts from an Android application.
The flow is similar to this.
The user chooses if he wants to use Buzz.
Using OAuth/Client Auth, we need to get a one-time authorization code.
This code would be used by a web service to periodically read Buzz feeds.
Now, the problem is how do I obtain the authorization code (Not temporary token) from the Android App and send it to the webservice.
I could use the normal OAuth2.0 and use my webservice as the redirect URL to obtain the code. But in that case how can I let the webservice know that the code pertains to which user?
Can I pass extra information with the OAuth dance?
I strongly recommend using OAuth 2. The flow is much better for the end user and it's a lot easier to implement something like this. Additionally, it uses bearer tokens, which means that you can maintain your refresh token server side where it's actually secure and only ship access tokens to the Android when they're needed.
The downside of this approach is that effectively every time your app loads it needs to phone home to get the latest access token. But once it has that access token, it can make whatever API calls it needs to, directly to the Buzz and Contacts APIs.
However, to do this, you don't pass extra information with the OAuth dance. Instead, your Android app needs to have already securely identified which user is signed in with your app, and then make sure the server only ever sends back access tokens associated with the authenticated user. If it doesn't have an up-to-date access token for that user, it would need to make a request out to Google's authorization server to get the latest access token, and then pass it up to the client. So there's certainly a strong potential for some latency there, because that generally needs to be a synchronous call, but that's usually a small price to pay for the advantages OAuth 2 gives you over OAuth 1.