Using HTTP Digest Authentication on the iPhone

Question

I have an app that communicates with a server that uses HTTP Digest authentication.

It seems to me that the 'session' management within the iPhone is pretty "black box" to us developers. Is it true that we can't see how the framework handles / persists http sessions?

If I'm just being dim here, would someone care to explain how to probably handle HTTP Digest authentication on the iPhone?

My basic run through is:

• Make a request to a secured url
• Server sends a 401
• client creates and persists a credential, and passes it back to the server
• server verifies credential, completes request if verified, sends another 401 if not.
• make a subsequent request to secure url
• server requests authorisation again........

This works for single requests, but if I make additional, subsequent requests, the server requests authorisation again. The server has persisted a session for the particular user, but the iPhone isn't making a request within the same session for some reason... Therefore, the server has to throw out the authentication object and create a new one each time the client makes a request to a secured url.

I'm sure this isn't correct behaviour.

If we look at how a browser behaves in this situation:

• Browser requests data from secure url
• server sends 401
• browser prompts user for credential, persists it, passes it to server
• server verifies credential, returning data if verified, sends another 401 if not.
• subsequent requests made to secure urls are not prompted for credentials because the browser manages the session.

I'm creating the NSURLCredential and persisting it within the NSURLCrendtialStorage. Then when the app receives the 'didReceiveAuthenticationChallenge' I retrieve the credential from the storage and pass it back, creating the credential if it doesn't exist (on the first request).

Any help would be greatly appreciated. Thanks.

Mitinger

Answer 1

First thing, is to forget about HTTP sessions, as these do not interact with Digest authentication active log-ins (there is a sort of session info ability, but it's different).

Indeed, one of the main reasons for using Digest, is to not have to use sessions just to maintain a logged-in state. Sessions are heavy and hurt scalability.

I couldn't say for sure what your issue is, but I do know what I would check on first, which is correct use of stale and correct creation of nonces.

User-agents can only handle authentication without requerying the user if they are asked to handle the same nonce, or in another case I will come to later (easier to explain it in this order).

If you have the same nonce used in each request, then the user-agent will continue to use it along with the "ha1" from the user/pass to request subsequent resources. This is done preëmptively, so the challenge never happens.

Of course, using the same nonce introduces an element of insecurity, as replay attacks become trivial to anyone that can sniff the traffic. Nonces will have to change on a regular basis.

Hence, if you receive a request from a user-agent with an invalid Authorization header, but the reason it is invalid is that the nonce is wrong (it's using an expired one) then in your challenge include "stale=true" (defaults to false). This informs the user-agent that your reason for rejecting is the nonce is outdated (of course the other information may also be wrong, but that doesn't matter as you aren't going to let it play either way).

On receiving such a stale=true the user-agent will know that it isn't authorised, but instead of requerying the user (or throwing an exception if it's a UI-less component) will retry the old criteria with the new nonce.

I can't tell if any of this is what's affecting you, but the way nonces and staleness are determined and signalled is certainly the first thing I'd look at.

Mathewmathews

Jasarien, Do I take the tick as meaning this put you on the right track? (for my curiosity, and perhaps the benefit of someone else finding the same issue). – Mathewmathews

Answer 2

I've written an iPhone app with HTTP authentication and experienced what you describe. (My application uses basic authentication instead of digest authentication, but that doesn't make a big difference here.)

The cause of the problem is on the iPhone side. The server is required to answer with 401 if the iPhone doesn't send the credentials in the HTTP request header. And in fact it doesn't even though it easily could once the credential is stored in the credential storage.

This strange behavior had a severe effect on the speed of the application since every request caused two round-trips to the server instead of one (the first one with status 401, the second with 200).

I've solved it by manually setting the credentials in the HTTP request header:

NSString* credentials = [NSString stringWithFormat: @"%@:%@", usr, pwd];
const char* credentialsChars = [credentials cStringUsingEncoding: NSUTF8StringEncoding];
credentials = [CommunicationUtil stringBase64WithData: (const UInt8*) credentialsChars length: strlen(credentialsChars)];
NSString* authorizationHeader = [NSString stringWithFormat: @"Basic %@", credentials];

NSMutableURLRequest* request =
    [[NSMutableURLRequest alloc] initWithURL: url 
        cachePolicy: NSURLRequestReloadIgnoringLocalCacheData
        timeoutInterval: 15];

    [request setValue: authorizationHeader forHTTPHeaderField: @"Authorization"];

Now my application works very smoothly and is very responsive.

The solution will look slightly different for digest authentication. But you'll get the idea.

Blastoff

Digest authentication will look very different. If ASIHTTPRequest supports it already, I'd use that instead of fudging some crypto. – Peeper

According to the docs, ASIHTTPRequest does, so I'd go with tc's suggestion. It'll save you a lot of headache from having to code all of this stuff manually – Coshow

I've studied the details of digest authentication and I have to agree: I quite cumbersome to implement. Computing the MD5 hashes is the easiest part. Handling all the details in the HTTP header is the hard part. So yes: It's probably best to give ASIHTTPRequest a try. – Blastoff