{Mobile Portland} Question about remote authentication

[Preston Crawford]

I'm working on learning Android development and I had a question. If I wanted to develop an app that authenticated remotely with my own web service or something like Google, what would that "mean" exactly. By that I mean, in the mobile space how do you typically handle authentication like that? I come from a web development background and there it's pretty straight-forward. You login and once you've logged in you have credentials that are checked whenever we pull specific content for you or check to see if you can perform a specific action on the web app.

What would that model look like with a remote application like a mobile app? Would you login, return a token (key of some kind) and then just pass that to web services whenever you called them? My guess is that you would create a session (assuming you have a load balanced service with a database-based session system) and return a key to the client. Then the client would present that key whenever it wanted to login and that key would be tied to that user, thus allowing the system to determine if a particular action were allowed to be performed by that remote client. 

Does that sound correct?

Preston

--
You received this message because you are subscribed to the Google Groups "Mobile Portland" group.
To post to this group, send email to mobile-...@googlegroups.com.
To unsubscribe from this group, send email to mobile-portla...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mobile-portland?hl=en.

[Jer Warren]

There are a few ways you could go about it, but you're headed in the right direction. Android has a CookieManager that you can use to store/fetch cookies, either in a WebView that's loading your url, in an http fetch process, or a combination of both.

Essentially the auth is done exactly like a browser, it's just a matter of replicating that functionality in your app.

For instance, say your app needs to log in, fetch a list of items, then post changes. You'd have the username/password stored on the mobile app, so you could run the login request, store the cookie it returns, and use it again in subsequent requests.

[Adrian Harris Crowne]

I'm not sure if this is what you're asking, but more and more sites are integrating OAuth and similar authentication systems into their APIs for that purpose. Another standard is OpenID.  Twitter and some other services use http authentication, but someone recently told me that Twitter is abandoning that for OAuth like this month or something.

OAuth and OpenID are pretty challenging, especially without former security knowledge.  There is a OAuth library for the iPhone called MPOAuthMobile which works, but it has a steep learning curve--but not as steep as actually doing OAuth yourself!

Anyway, I would bet there are similar Android libraries, possibly even a version of the same library ported.

Hope that helps,

Adrian

[Preston Crawford]

Yeah, I'm a little turned around on this right now. I talked to someone recently who advocated, since I'm using REST, that I go with using HTTP auth to handle authentication and then store the username / password on the client when the client is "logged in". Then each request to the REST services could be accompanied by the username / password and there would always be a challenge / response at that point. 

That made sense and all seemed very pure HTTP and pure rest. The problem is that as I take a look at going that direction it's proving to be very difficult. So I'm not sure if at a certain point it isn't better to go with OAuth.

All I know is this. I'm trying to, in a reasonable amount of time, get to a point where I authenticate against a web service and have some way to keep state (probably on the client it's looking like) so I can use those same credentials over and over again without asking the user for them again. And I'm trying to do this the most standard way that makes sense.

Preston

[HiQuLABS]

It may be too late. You may want to check out Persevere http://docs.persvr.org/

[Jeremy Logan]

Maybe I'm missing something, but what's the problem with just using HTTP authentication on every request?

[jonathan karon]

On Apr 28, 2010, at 10:29 AM, Preston Crawford wrote:

> Yeah, I'm a little turned around on this right now. I talked to someone recently who advocated, since I'm using REST, that I go with using HTTP auth to handle authentication and then store the username / password on the client when the client is "logged in". Then each request to the REST services could be accompanied by the username / password and there would always be a challenge / response at that point.
>
> That made sense and all seemed very pure HTTP and pure rest. The problem is that as I take a look at going that direction it's proving to be very difficult. So I'm not sure if at a certain point it isn't better to go with OAuth.
>

Preston,

Are the REST services you're accessing using standard HTTP Basic authentication? If so then there really isn't any sense of "logging in" for a client (you may know this but I just wanted to confirm.)

I haven't worked with the Android HttpRequest* API, but it may be as simple as using a URI of the form http://username:password@host/path/

Alternatively, look into ways to add a header to your HTTP request and set the Authorization header. The header should be of the form:

Authorization: Basic HASH

Where HASH is a base64-encoded string, computed with: base64encode(username+":"+password)

I can guarantee that, if your RESTful service is using HTTP Basic Auth, this will be far easier than implementing OAuth.

~jonathan

[Preston Crawford]

Nothing. That's the direction I'm going in right now. Using HTTP auth protocol, but authenticating against our user database. It's just that as I work on this something like OpenAuth pops up and I wonder if I should be considering that.

Sent from my iPhone

[Preston]

This is proving to be ridiculously hard under Android. I'm not sure
what I'm doing wrong. I'm using the HttpClient and trying to pass
username / password using standard REST techniques (Http auth).
However, I'm running into a significant problem with getting this to
work right. Has anyone done this on Android?

Preston

On Apr 28, 11:25 am, Preston Crawford <preston.crawf...@gmail.com>
wrote:

> Nothing. That's the direction I'm going in right now. Using HTTP auth  
> protocol, but authenticating against our user database. It's just that  
> as I work on this something like OpenAuth pops up and I wonder if I  
> should be considering that.
>
> Sent from my iPhone
>

> On Apr 28, 2010, at 10:48 AM, Jeremy Logan <jeremy.lo...@gmail.com>  

> wrote:
>
>
>
>
>
> > Maybe I'm missing something, but what's the problem with just using  
> > HTTP authentication on every request?
>

> > On Wed, Apr 28, 2010 at 10:29 AM, Preston Crawford <preston.crawf...@gmail.com

> > > wrote:
> > Yeah, I'm a little turned around on this right now. I talked to  
> > someone recently who advocated, since I'm using REST, that I go with  
> > using HTTP auth to handle authentication and then store the  
> > username / password on the client when the client is "logged in".  
> > Then each request to the REST services could be accompanied by the  
> > username / password and there would always be a challenge / response  
> > at that point.
>
> > That made sense and all seemed very pure HTTP and pure rest. The  
> > problem is that as I take a look at going that direction it's  
> > proving to be very difficult. So I'm not sure if at a certain point  
> > it isn't better to go with OAuth.
>
> > All I know is this. I'm trying to, in a reasonable amount of time,  
> > get to a point where I authenticate against a web service and have  
> > some way to keep state (probably on the client it's looking like) so  
> > I can use those same credentials over and over again without asking  
> > the user for them again. And I'm trying to do this the most standard  
> > way that makes sense.
>
> > Preston
>

> > On Tue, Apr 27, 2010 at 9:42 AM, Adrian Harris Crowne <aharriscro...@gmail.com

> > > wrote:
> > I'm not sure if this is what you're asking, but more and more sites  
> > are integrating OAuth and similar authentication systems into their  
> > APIs for that purpose. Another standard is OpenID.  Twitter and some  
> > other services use http authentication, but someone recently told me  
> > that Twitter is abandoning that for OAuth like this month or  
> > something.
>
> > OAuth and OpenID are pretty challenging, especially without former  
> > security knowledge.  There is a OAuth library for the iPhone called  
> > MPOAuthMobile which works, but it has a steep learning curve--but  
> > not as steep as actually doing OAuth yourself!
>
> > Anyway, I would bet there are similar Android libraries, possibly  
> > even a version of the same library ported.
>
> > Hope that helps,
> > Adrian
>

> > On Tue, Apr 27, 2010 at 1:39 AM, Preston Crawford <preston.crawf...@gmail.com

> For more options, visit this group athttp://groups.google.com/group/mobile-portland?hl=en.

[Preston Crawford]

Okay, I've narrowed my question down. Basically it's this. I need to use preemptive authentication as I'm writing my own REST services and not issuing a standard challenge / response, but rather just expecting a correct username and password and using HTTP to transport it. So if anyone has done something like this on Android my question would be how you setup a CredentialsProvider so that it has that username and password in the HttpRequestInterceptor.

Preston

[Jeremy Logan]

I've done this in Android, but not w/ preemptive authentication. Why not just have the server complain if it doesn't get the credentials? Something like this (in PHP) should do it (I just wrote this on the fly, so it isn't tested):

if (empty($_SERVER['PHP_AUTH_USER']) || empty($_SERVER['PHP_AUTH_PW']) {
    header('WWW-Authenticate: Basic realm="example.com"');
    header('HTTP/1.0 401 Unauthorized');
    die();
}

Also, after poking Google for a few minutes I found this. It looks like this might work:

client.getParams().setAuthenticationPreemptive(true);
Credentials defaultcreds = new UsernamePasswordCredentials("username", "password");
client.getState().setCredentials(new AuthScope("example.com", 80, AuthScope.ANY_REALM), defaultcreds);

Jeremy Logan

[Preston Crawford]

Thanks, Jeremy.

The deeper I've gotten into this problem the more I've discovered about my misconceptions, etc. Basically since I'm going to be making many service calls I need to setup HttpClient as a singleton. And when it's launched basically I can seed it with the credentials after the user has logged in and I've saved the credentials to the device. At least, that seems to be the right way forward. 

As to the idea of forcing the REST side to challenge I'm not sure that would work. Reason being that I would have to handle that on the client side, wouldn't I? I mean, it wouldn't immediately send back the credentials I'd already set, would it?

Preston

[Sean Sullivan]

HttpClient allows for pre-emptive authentication.  Examples are available here:

   http://hc.apache.org/httpcomponents-client/examples.html

On a related topic,  I am giving a presentation titled 'Connecting to Web Services on Android' at Open Source Bridge next month.

    http://opensourcebridge.org/sessions/448

The presentation will include these topics:  HttpClient, JSON, XML, HTTP authentication, and OAuth.

Sean

On Thu, May 6, 2010 at 6:20 PM, Preston Crawford <preston....@gmail.com> wrote:

[Jeremy Logan]

It's been a while since I've done this, but I think that the way it works (by default) is something like this:  set up the credentials (any point ahead of time) -> make the request -> HttpClient makes the request w/o credentials -> the server demands credentials -> HttpClient makes another request, this time using the credentials set up before -> magic!

At least that's what I think I remember. Basically, unless you tell it to be preemptive it waits until it's challenged, but it still handles the interaction.

The reason I like the idea of setting it up on the server side to announce that you expect authentication is it lets anyone who wanders across one of these URLs know what's going on... especially you in 2 years ;)

Jeremy

[Preston Crawford]

For whatever reason I can't call that method in the SDK. The one where you directly set preemptive authentication. No idea why. Also, my understanding is that Interceptor is the favored way to go now. This is really the crux of the matter right now. That interceptor has to be static, essentially, yet I need it to pull the username and password from at least the application data store.

As for the presentation? I can't wait and it can't come soon enough for me right now. :)

Preston

[Preston Crawford]

Jeremy, 

Challenging worked like that. That's amazing. I literally did something almost like this. I sent the response differently and it didn't work. But your example did. Thank you so much!! Now I just need to get the client into a proper singleton just because it's the right thing to do. No need for the interceptor now. Whew!

Preston

On Thu, May 6, 2010 at 6:35 PM, Jeremy Logan <jeremy...@gmail.com> wrote:

[Jeremy Logan]

No problem. I seem to remember that Android's copy of the HttpClient stuff is one major version behind, so maybe that code was specific to the newer version.

Just for future reference, I've had really good luck getting questions answered on StackOverflow. It might be worth taking a look at if you get stuck again.

Jeremy

[Preston Crawford]

Scratch that. The client on the Android app never tries to reauthenticate. False alarm.

Preston

[Jeremy Logan]

Dunno... try http://dlinsin.blogspot.com/2009/08/http-basic-authentication-with-android.html

[Preston Crawford]

That's exactly the page I was working off to start. The problem is figuring out how to get the credentials for the client into that call.

Preston

[Preston Crawford]

Okay, this is so silly. Somewhere in the process of constructing a URI object I was missing the scheme. It worked for the rest of the code, but threw an obscure exception (something about a missing target) with it gone. Once I added it it worked. Now to just get the client running as a singleton and work on getting the connection to be made under SSL.

Preston