Support for refresh token

[fvisticot]

On 401 : authorization failed with expiration token, we need to ask for a new token (refresh_token)
It would be nice to have a complete integration of the oAuth flow in this framework.

If I'm correct a solution would be to overload AFHTTPSessionManager: dataTaskWithRequest

I'have made a first try but it is not working yet.

[battlmonstr]

This is a related issue to #12
The solution from @mattt there is not working anymore, because the AFNetworking is no longer based on NSOperation, and the session data tasks can't be chained trivially.

It would be really nice to have a solution or a workaround for this.

Example

This is the situation I often find myself in:

• REST API
• OAuth with JWT tokens
  The token has an "exp" field in the payload - a well-defined token expiration time (a unix time int).

That could be different from implementation to implementation, but this could be generalized in the framework by an injectable protocol that is used to get the token expiration date.

Some requests require a token, some doesn't, but those that require can return 401, and fail. In this case it (most of the time, but not always) indicates that the access token is expired and needs to be refreshed.

Refresh logic

To refresh the token I have another AFNetworking HTTP request (can be a GET, can be a POST), but it is constructed via the framework somehow in my code. This could be also generalized by a framework protocol, which is a kind of a factory that can create such request.

The correct logic is not trivial (although in some cases a trivial solution is acceptable): if the token is about to expire, all incoming and pending requests need to be put on hold, and wait for the refresh to happen. This is to be done either before a new request arrives, or after it returns 401, but in any case it shouldn't be repeated many times in a short time frame (assuming here that the access token normally lives for at least several minutes). When the refresh succeeds, the pending requests need to be restarted with a new token.

For this logic to work across all the REST calls and endpoints a client app would have to build a layer on top of AFNetworking that generalizes all the requests, and implement the queueing-retrying logic. Having this layer inside the framework (maybe optional) helps a lot on a large scale.

I can imagine that if some people are not using OAuth, but are using cookies and passwords, then some of them could still benefit from transparent re-authentication in case when a cookie expires. Many iOS apps prefer to never log out. This case could be covered by the same generic refresh logic.

P.S. Android has a nice solution to this - Interceptors, which work transparently. It is a pity that AFNetworking doesn't support it.