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.
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.