It's not possible to retrieve secondary data from the authentication request

[blixt]

It's not uncommon to include additional data in a successful OAuth response. How come only the token is accessible in the success handler?

I realize this won't be easy to change for backwards compatibility reasons, but if a major version is coming up, it would be nice to have the block signatures (mostly) match all the standard AFNetworking ones by simply adding the AFHTTPRequestOperation *operation parameter in front. While the second argument to success would still be AFOAuthCredential, the developer can choose to extract extra parameters from the AFHTTPRequestOperation instance's responseObject property.

In the meantime, perhaps something could be done to support accessing the additional parameters?

[blixt]

For some examples of OAuth endpoints that return extra data you can find some here:

• https://developers.facebook.com/docs/facebook-login/access-tokens (e.g., machine_id field)
• https://developers.google.com/oauthplayground/ (e.g., Google+ returns additional fields)
• https://developer.paypal.com/docs/integration/direct/make-your-first-call/ (e.g., app_id field)

[itsthejb]

Indeed, same issue here - most OAuth APIs I've worked with return the authenticated user in the auth request success response.

[OmarPedraza]

+1

The OAuth2 server I'm working with returns a bad request status when user or password are invalid and includes a description error in the responseObject, so I need to access to the responseObject to give the user more information about the error.

[jroa919]

+1

Our OAuth2 server also returns HTTP/1.1 400 Bad request for an invalid username/password combination. AFNetworking returns this as an error and this is obscured when the failure(...) block omits the data task argument.

On the topic of extendability, we are using an OpenID Connect server that returns additional information in the authentication request responseObject (such as 'id_token', etc.). This information is also lost in the success(...) block.

Looking at #112, those changes achieve exactly what I'm looking for. Hoping to see this merged into the 3_0_0_branch.

[boojapathyc]

any updates on this issue.