I'm not sure how to go with authentication method
I have a way but don't know if it is secure or not. let me explain what I'm doing with REST API.
I have a multiple users based web app, where users can login with their user name and password and do the stuff.
I need to develop a mobile app for that web app. I'm thinking REST with Slim Framework, However I have no
problem with Slim REST development but the authentication part is what I am not sure how to develop.
However I have some idea
Use session cookies :- When user login via mobile app call REST API authentication method, make database query
and match username/password. If they does match create two cookie for user name and password and store them in encrypted form
When mobile app send next request check the cookies, decypt the user name and password, again match with the database record
if matched call Requested method otherwise deny the access.
Please let me know how I am going?
Does it still make my REST API RESTful?
Is it okay to store username/password in cookies for above senerio?
Related
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
I've got a web app that currently allows users to login via Facebook. This is the only login mechanism at present. I make use of the user id and the users friends to perform certain actions. Now I want to create an api that I can use to create a native mobile app. To do this, I would need to authenticate users against the api. I've looked at this question
Possible approach to secure a Rest API endpoints using Facebook OAuth
but I don't actually have a "user" table as I only pull the facebook info when I need it. In iOS or something similar I could obviously make use of the native facebook sdk and then call my api, passing in the required user id and friend ids etc. however I'm not sure then how I could specifically secure my api so that if a user got hold of another's user_id they could in theory retrieve info via the api or in theory any resource that only specific users should be able to see
I thought about creating an app_id and app_secret for all the separate apps consuming the api. I would then use the appropriate secret to encrypt the data being sent and returned. The api and native app would know the secret and be able to decrypt it and validate that a user can view the requested resource. Does this sounds like a valid approach? In theory only the native apps would then be able to decrypt what is returned from the api. Or should this really be done on a user by user basis as recommended in the linked post?
All of this would be done over https
Thanks
Not familiar with the Facebook API nor iOS so I am speaking completely in theoretical terms.
Could you not:
Ask the user to login with Facebook on the iOS app
Send the login data over a secure channel to your web application to handle the actual processing of the data
Send the iOS app a secure hash for authentication
Use your web application as needed; using the hash for authentication, make HTTPS requests as you would your web application and use the responses from the webserver to populate the iOS app
If you make a user_hash column a complex salted hash like a SHA-256 (or greater) hash, the user_hash will become invalid before anybody is able to guess the hash. You could save the user's Facebook credentials locally on the iOS device and then renew the hash every so often, as to invalidate old hashes and lock out perpetrators (like how a cookie expires). If the user hash somehow becomes invalidated while using the iOS app, the app will send the locally stored credentials and retrieve a new one.
If Apple offers cookies for apps, you could send the hash in a cookie from your webpage and give it a reasonable expiry time (e.g. 1 day). You'd be resending the locally stored Facebook credentials every day and be effectively locking out anybody trying to bruteforce your hashes. Use that instead of trying to implement cookies from scratch (if the iOS API offers that), but as I said, I'm unfamiliar with iOS.
From an SQL standpoint, your webpage would validate a user's Facebook credentials, create a new row with a randomly generated user_hash, expires timestamp, user_id, friends_id, etc. Every user that uses the webpage will have to send the user_hash either from their web-client or the iOS app and will be checked against the database. If the present timestamp exceeds the expires timestamp, the session is ruled invalid and the user cannot operate your application.
Of course, you'd need to encrypt the communication. Do you pass credentials everytime the user loads a page on your web app? Or do you store them in a session?
Hope this helps at least somewhat!
https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSHTTPCookieStorage_Class/Reference/Reference.html
I want to create a chat application with two forms of login, a standard login form with username and password, and a secondary method using single sign in for logging in using facebook, but the user only needs to specify a username.
I'm planning on designing the application in two parts, a server side module which will be my own custom rest api, and an android application module.
I would like a way to authenticate the user from the server side. I was thinking of having the android application send an facebook api access token to my server, and then having my server check if it works for accessing their private data, but I'm unsure if this is valid enough proof that it is the original user. Is there a more standard way of checking if a the facebook user is who they say they are?
I'm trying to build a Facebook-authenticated native mobile app (Windows Phone) that connects to a web service I am creating in Node.
I'd like for a user to:
Log in to Facebook on the mobile app via a native UI or web window
If logged in successfully, create or access server-side user account data tied to that identity
Use the authenticated session to make subsequent authenticated requestsvto that user's data via the native mobile app
My question is: What's the best approach here?
Should I...
Log in the client to facebook locally in the mobile app and pass the Access Token to the node service, and then somehow map the user to my service data based on their facebook account id? That seems grossly insecure if I just pass that token in the URL.
Log the user in via a mobile browser window inside my app, and then redirect back to my Node service in the same window? How do I then make subsequent authenticated requests natively in my app?
Do something else entirely?
Sorry this is so open ended but this is the first time I have tied these things together and although there's a lot of info on each part I've yet to find something that describes the overall pattern / best practice for this design.
Your question is quite opinion based...but still I will try to help.
First of all, you can pass access token in url, its not insecure if you use https. Even if logged into facebook from your mobile app, than also its going to pass a access token in url only. If you mean having the token in http://something.com/access_token, than its not how its should be done.
If you look into the Oauth 2.0 draft you will understand that its done through setting a header Authorization with the value being the token and token_type. Take a good look at the draft.
As your solution I think its fine if you just use the first method mentioned in the question by sending the access token in header as I mentioned in your app and in turn authenticating that token from facebook on each request.
If you think this is just too long a flow for authenticating every request from facebook, than you can get access token by sending request from your mobile app to server and let the server handle the access token and store it in database which you can authenticate each request.
In any case take a look at Passport module, it has facebook and other auth built-in and should be sufficient for your needs.
I am building an iOS application and I need to be able to make authenticated requests to a Rails 3 application for various bits of data. The Rails 3 application is using omniauth and URLs like https://myapp.com/auth/facebook to, for example, authenticate users via facebook ... and once authenticated, stores the authentication in a secured cookie named "auth.""
What I want to know is how to authenticate my users from the iOS/iPhone application, persist the authentication token and send it along with future requests to the Rails application?
Using ASIHTTPRequest I'm thinking of doing something like this:
Open a UIWebview, loading with a URL from my web application specific for the provider they want to authenticate with (e.g. myapp.com/auth/facebook for facebook or myapp.com/auth/yahoo for yahoo, etc....).
On success, somehow parse out and store the authentication cookie in the iOS application without displaying the webpage folks usually see when authenticating via the website ... and instead closing the UIWebView and navigating back to another UIVewController in the iOS application.
Somehow include the persisted authentication token with future web requests to the Rails application.
I also want to allow users to allow the iOS application to store this information locally so they don't have to re-login to the remote application if they choose too.
Is this approach appropriate? Is there a better way? And of course, how to actually implement the above?
Thanks - wg
Using OAuth is pretty easy (well, easy is not the word...), but I made an iOS application and a java server that use OAUth as identity schema and, following the full cycle, finally I adquired a token that identifies this user and (as only can be accessed using signed requests) can be safely stored in the phone (I use just the standardUserDefaults to store it). Only your application (using the secret) can sign the requests.
I don't know if this serves to you...
Ah! After the identification via web, the browser redirect a special url (registered for my application) and the url opens my application including the token in its parameters, so it is easy to retrieve the token after the identification phase in handleOpenURL.
Once the UIWebview has authenticated with said service, get it to load another URL (for example: through a javascript on the page which said service returns to after authentication).
Capture this request using a UIWebViewDelegate object which implements the following protocol method:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
From here you have the NSURLRequest object. You can extract the headers of the request to NSDictionary which will contain the authentication cookie details, token, etc. using the following method of NSURLRequest
- (NSDictionary *)allHTTPHeaderFields
For my app this is what I'm doing.
My app is using devise with omniauth for login and user stuff.
Devise by itself can generate a unique token, with the flag token_authenticatable.
So on my login request, if the login is successful I reply with a JSON representation of my user and my user token. I save all that on the phone memory.
Then on every request I add the param auth_token=MY_USER_TOKEN.
And that's about it.
I had just a problem with the Facebook auth, because I'm using the Ios facebook SDK, so I forward the FB token to my app, verify it, and then just return the same devise auth_token for all following requests.
Ok here we go, I dont know the exact setup of your web service and all that, but what you can do is store the authentication token on the device using SQLite or Core Data, I am currently working on a app that requires authentication, and what I do is store the username and password locally on the device in the SQLite db using Core Data to interact with the db, then whenever I make an API calls I use the stored username and password for the authentication on the server side using gets, but I believe it is saver using post, as long as the web server has great security I don't believe there is any security risks. In what I understand about what you are building I would authenticate the user say on first launch and have the user be able to change log in credentials at a later stage, but after authentication I would send back an authentication token to the device and store that in the db and then whenever I need to authenticate with the web service I would send the auth token with a post request to the server. Does this make sense?