Lets say there is a website that doesn't provide an api service. However, a legitimate android app wants to provide a useful service. So first they ask the user to create an account on that website. Then once the user is logged in, they would be able to perform certain functions like "liking" a post, or commenting on stuff, right from the app. But obviously a CSRF token is used for all form submissions. So are android apps capable of grabbing this token? If not is there a way to ask a user for permission to grab it? Also if the same app was made for iOS would the functionality work the same?
Thanks.
Assuming the app makes the login request on behalf of the user and stores the authentication cookies for use in the subsequent requests, then yes.
A GET request would need to be made to the web page with the form on it, the CSRF token parsed and then a POST request would be made passing all the required parameters (including token).
Yes this could be done with iOS too.
Related
I'd like to a make a mobile app that makes requests on behalf of a user. I understand the following OAuth flow:
Open user in web view to give my app access to make requests on their behalf
When they hit grant access, my server side app will receive a call with an authorization code
My server side app then needs to exchange the authorization code for an access token
My confusion starts in Step 2. Uber makes a request to my endpoint with the authorization code, but I have no way of knowing what user that authorization belongs to. I can exchange it for an access token and store it in a DB for 30 days, but I have no way of getting it back to the user to use to make requests.
One thought was I could have the user sign in to my app with an email address which I could then use as a key to get the appropriate access token from my server app, but I have no way of associating the access token with an email address in my DB table in the first place.
I'm wondering what the best practices are here. How is my mobile app supposed to know what access token to use for a given user?
(I reached out to Uber API support directly, but they asked me to open a StackOverflow question instead)
Obviously this is kind of a broad question and is highly dependent on what type of app you're building, what you want the user-flow to look like, etc etc but I'll do my best to point you in the right direction.
First, the Uber API has the /v1/me endpoint which will return the users first name, last name, and email address, among other things. So one possible flow is that a User opens your app, they then go through the whole OAuth flow, and once you exchange the authorization code for an access token you immediately use it (from the server) to make a call out to the /v1/me endpoint and then use either the users email address or UUID as a key in your database. If you used email address, you could just allow users to login to your app using this same email address and allow the account creation process to just be the OAuth flow.
I'm not a mobile developer, but my understanding of embedded web views is that they can use cookies just like any other browser. In that case, another thing you could use is sessions / cookies. Assuming you have some kind of identifier for your existing users, you could add that as a cookie for your web server and then when your user gets redirected to your web server with the authorization code, the attached cookie will tell you which user to associate the access token.
Finally, the Uber developer platform includes a state parameter in the authorization phase of the OAuth flow as seen here https://developer.uber.com/docs/authentication You could do something similar to what I describe in the previous paragraph, except instead of using cookies you could store the user identifier in the state parameter and it'll be sent back to you when the user re-directs. You can use that piece of information to tie the access token back to a specific user in your DB.
I hope that helps! Don't hesitate to reach out if you're still confused.
Cheers!
I have a background in web development but I am very new to the mobile world. So, I'm not sure how to proceed with this situation:
The user login in the app
The credentials are sent to the server through a POST request.
If the response is ok, it redirects to the main activity.
Now, I want to know if I have to keep the user's ID or not. I know that when we are using a browser the server saves a "session" so the client doesn't need to send the ID everytime to request data. Is that also true with mobile apps (Android)?
By the way, I'm also responsible for building the REST API but don't have any experience targeting mobile devices.
Big question to answer, and it depends and not sure what server technology you are using. However I can describe an approach I implemented (.Net background).
It seems you are writing a mobile app?
The mobile app would first make an authentication call passing id and password to your login api, over https of course. Often the url would be something like
//yourwebsite/Account/Token
Your api would validate the user and if ok, issue a bearer token.
The mobile app needs to remember this token and on subsequent calls pass this in the request header. That's how the server will know who this is. You don't need to send the user id and password any more. And there may be a strong security argument for not storing the user id and password on the mobile device at all.
Now, your server code will validate the token, and you will know who and what the user can do. The token typically expires, so any mobile client needs to check for this and re-authenticate to get a fresh token.
But how will the server know this token, who it belongs to?
In an MVC world for example, there's framework code to help here. There's plenty of MVC template code. If you happen to be developing .Net api services, see this http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
If you are not .Net on the server, I'm sure there will be something else to help you along the same principals.
As for developing RESTful API's, ServiceStack is seriously worth considering. If too expensive, at least consider their approach and roll your own (especially when it comes to versioning of your api's).
You misunderstand the case with browsers, therefore your conclusion is flawed. Let me explain: When you log in to a website using a web-browser, a session is saved indeed, but not only on the server. It is saved at the client-side as well. Whenever you send a request from there on to the server, you have to send that stored information as well, called cookie to identify yourself.
Let's think about this more deeply: How would a server identify your session as being your session without getting a cookie? By IP address? Nope, the IP address can be used by many and it might change. By browser session? Yes, by browser session, which includes the cookie as well.
Now that you understand that the session is saved by both the server and the client, you surely already know that you need the very same for mobile apps as well. The client logs in, therefore a cookie is generated for the client. This should be difficult to guess. From there on, the client uses the server using the cookie created for it.
If you do not believe me, visit a website where you are not logged in, and then run console.log(document.cookie);, log in, then run console.log(document.cookie) again, then log out andd run console.log(document.cookie) again.
I'm developing an android app that consumes a webservice that I will develop too (I'm thinking in using a RESTFul webservice)..
and I want to secure the connection between the app and the server but I need to authenticate users too..
My problem is in the last part, to secure the connection I think the best way to do it is to use SSL (https), am I wrong?
I don't know what's "the best way" to authenticate users, to make sure that a user cannot consume the webservice as another user..
I have some ideas, like using a authenticate(login,pass) method on the webservice that returns a token.. And for any operation that requires authentication the user would need to pass that token as a parameter.. The thing is, is this a good way to do this? whats the most common technique used to auth users in a situation like this?
If a token based auth is a good idea how should I generate the token?
Sorry for this long text..
Any help will be usefull
Thanks
Make sure you understand a trendy standard like OAuth before you go down that path. Most OAuth flows are centered around a user logging in to your server through a web browser. This can lead to pretty bad user experience for a mobile app. The standard does allow for alternatives. Here's a decent introduction.
You could also use an existing identity provider like Google, Facebook, Twitter, etc. instead of implementing your own authN/authZ. On Android, you can ask for a Google auth token using the AccountManager. This usually works because the user needs to be logged in to their Google account to access the Android Market. Anyway, this will prompt the user to grant authorization to your app. You could then use the Google auth token to login your user to your service with your own token. The login would essentially be your server verifying the Google token is valid (by contacting Google's servers) and then issuing its own token to be used for calls to your web services. If you don't like Google, you could use the Facebook SDK, etc.
As for what to use for tokens... The OAuth spec has stuff on that as well. You could do something as simple as a random string or something as complex as encrypted SAML assertions.
You should implement a token based OAuth, which will require the users to log in once, and then permanently have access.
You can use Google App Engine which already provides user authentication services for you (your Android users most likely already have google accounts) But this is only one of many options.
You can also look into Amazon's Identity Access Management (IAM) which will allow you to manage the users who have access to your web service, and authorize them accordingly.
I think the best way to do it is to use SSL (https), am I wrong?
This only prevents certain types of malicious use, but not everything. There is still nothing to prevent people from accessing your database on the phone, and retrieving credentials that way.
I have a rails app (rails3) that uses sessions for users to navigate upon login. I am trying to create an android app for this rails server and trying to figure out what is the best way for handling login is.
From what I've found so far, there are two possible ways:
1. Get sessions from rails server and setCookie on android side upon login
2. Use OAuth.
Which would you recommend?
At this point, I am unsure of how to manage sessions when using OAuth, that's why I am asking the question. Thanks
I encounter this problem last time as well. As we need to allow logged in user in the android to be able to query the rails server for some data. Initially we thought about sending password/username from android and then set the session and cookies in rails server, then send back the info. Android then use this cookies to determine if the user is successfully login. However, in the end we didn't do this, as the cookie information maybe hard to manage in mobile device. In the end we create a separate protection scheme for the rails server, if the android send user/password, rails server would validate, if sucessfully, we will insert a encrypted token into the database that contains user name and token. For subsequent request, the android device must send token to rails server, if the token is valid and can be found in db, the validation passed,and we will return data.
Good thing about this is it is easier to manage users. E.g. you can easily manage how many concurrent loggin you allow for the user. Or even better if needed, you can kick out some users without touching the android apps. Not quite sure if this fits your questions. Just to share.
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.