Too many authorization bearers in MFP 8.0 - ibm-mobilefirst

Question

I've followed the steps provided in https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/authentication-and-security/protecting-external-resources/ to protect an external resource and https://mobilefirstplatform.ibmcloud.com/tutorials/en/foundation/8.0/application-development/resource-request/javascript/ to call via Cordova.
I'm making 2 request to the same REST method, which is protected with the scope "aovLogin".
It seems that every call is generating a new bearer token, which needs 4 extra calls to MFP.
Also, the first time a method is called, it makes several extra calls (it always goes http 401, then 403 then 200, making extra calls to MFP in the middle). If i have a very granular API, it's making a lot of extra calls.
I've seen that the server API has a cache for the bearers and the scope is configured for being valid for 10 minutes.
Why is the client sending so many authorization requests?
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
HTTP/1.1 401 Unauthorized
----------
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"","client_id":"3deccec7-3f18-4ee2-8464-de90a7c64685"}
HTTP/1.1 400 Bad Request
{"errorCode":"INVALID_CLIENT_ID","errorMsg":"Invalid client ID."}
------
POST /mfp/api/registration/v1/self HTTP/1.1
{"signedRegistrationData":{"header":"XXXXX","payload":"XXXXX","signature":"XXXXX"}}
HTTP/1.1 201 Created
-----
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 200 OK
{"successes":{"clockSynchronization":{"serverTimeStamp":1480322130967}}}
--------
GET /mfp/api/az/v1/authorization?response_type=code&scope=&client_id=84c45e4a-b75d-4125-ab9a-98f390d5bd3a&redirect_uri=http://mfpredirecturi&isAjaxRequest=true&x=0.1757133661526875 HTTP/1.1
HTTP/1.1 302 Found
------
POST /mfp/api/az/v1/token HTTP/1.1
XXXXX
HTTP/1.1 200 OK
{"access_token":"XXXXX","token_type":"Bearer","expires_in":3599,"scope":""}
---
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer XXXXX
{"idDelegation":"0801"}
HTTP/1.1 403 Forbidden
---
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"scope":"aovLogin","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 401 Unauthorized
{"successes":{"clockSynchronization":{"serverTimeStamp":1480322131320}},"challenges":{"aovLogin":{"remainingAttempts":5,"errorMsg":null}}}
---
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
{"challengeResponse":{"aovLogin":{"username":"XXXXX","tokenSEA":"XXXXX"}},"scope":"aovLogin","client_id":"84c45e4a-b75d-4125-ab9a-98f390d5bd3a"}
HTTP/1.1 200 OK
{"successes":{"aovLogin":{"user":{"id":"XXXXX","displayName":"XXXXX","authenticatedAt":1480322139874,"authenticatedBy":"aovLogin","attributes":{"tokenSEA":"XXXXX"}}},"clockSynchronization":{"serverTimeStamp":1480322139874}}}
--------
GET /mfp/api/az/v1/authorization?response_type=code&scope=aovLogin&client_id=84c45e4a-b75d-4125-ab9a-98f390d5bd3a&redirect_uri=http://mfpredirecturi&isAjaxRequest=true&x=0.5223292209780417 HTTP/1.1
HTTP/1.1 302 Found
---
POST /mfp/api/az/v1/token HTTP/1.1
XXXXX
HTTP/1.1 200 OK
{"access_token":"XXXXX","token_type":"Bearer","expires_in":599,"scope":"aovLogin"}
---
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6Ijg0YzQ1ZTRhLWI3NWQtNDEyNS1hYjlhLTk4ZjM5MGQ1YmQzYSIsIm4iOiJBTTBEZDd4QWR2NkgteWdMN3I4cUNMZEUtM0kya2s0NXpnWnREZF9xczhmdm5ZZmRpcVRTVjRfMnQ2T0dHOENWNUNlNDFQTXBJd21MNDEwWDlJWm52aHhvWWlGY01TYU9lSXFvZS1ySkEwdVp1dzJySGhYWjNXVkNlS2V6UlZjQ09Zc1FOLW1RSzBtZno1XzNvLWV2MFVZd1hrU093QkJsMUVocUl3VkR3T2llZzJKTUdsMEVYc1BaZmtOWkktSFU0b01paS1Uck5MelJXa01tTHZtMDloTDV6b3NVTkExNXZlQ0twaDJXcG1TbTJTNjFuRGhIN2dMRW95bURuVEVqUFk1QW9oMmluSS0zNlJHWVZNVVViTzQ2Q3JOVVl1SW9iT2lYbEx6QklodUlDcGZWZHhUX3g3c3RLWDVDOUJmTVRCNEdrT0hQNWNVdjdOejFkRGhJUHU4PSJ9fQ.eyJpc3MiOiJjb20uaWJtLm1mcCIsInN1YiI6Ijg0YzQ1ZTRhLWI3NWQtNDEyNS1hYjlhLTk4ZjM5MGQ1YmQzYSIsImF1ZCI6ImNvbS5pYm0ubWZwIiwiZXhwIjoxNDgwMzIyNzM5ODc0LCJzY29wZSI6ImFvdkxvZ2luIn0.jGJAhZaV6NFHZKj-LKBmJ6Gqb7ZrZX20xDKEPkNtORZ1tanLo8MSklY2HogK-wKs7APIuWESLSsskrwR9p0EnrmHgUYZf3BPY9HDUSBojUN9-vd_I9kavcg34Hes1KTvYG4Wi-9XbZQ2T1-SbHhn-mqsToeLIGBGkzsugwQG9tIKG3Qr0BixDIfuhxux4Gdo30HCyn9SB5ZaY5wdxaD2_kJjnJih_SsAuuXRNAXEO_PgExnZ6Mr1qyqyOfwc3k9jmgRpuEQigYYRYOP-Tvs_i59IVYOdpsQ70gi-Ky09orx5Jy3hVJv-J45Dx7FHdR3ZPTn7pYW7IRmRo4CZ2COoCg
HTTP/1.1 200 OK
.....
--- CALL AGAIN, new bearer is generated
POST /mfp/api/az/v1/introspection HTTP/1.1
POST /mfp/api/preauth/v1/preauthorize HTTP/1.1
GET /mfp/api/az/v1/authorization?XXX HTTP/1.1
POST /mfp/api/az/v1/token HTTP/1.1
POST /com.costaisa.app.api/api/mfprest/delegation/detail/private HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImp3ayI6eyJrdHkiOiJSU0EiLCJlIjoiQVFBQiIsImtpZCI6IjM1NDcyYWNhLWVlNmItNGNhZi04OGQ2LWQxY2ExNjQ0NzM4NyIsIm4iOiJBTTBEZDd4QWR2NkgteWdMN3I4cUNMZEUtM0kya2s0NXpnWnREZF9xczhmdm5ZZmRpcVRTVjRfMnQ2T0dHOENWNUNlNDFQTXBJd21MNDEwWDlJWm52aHhvWWlGY01TYU9lSXFvZS1ySkEwdVp1dzJySGhYWjNXVkNlS2V6UlZjQ09Zc1FOLW1RSzBtZno1XzNvLWV2MFVZd1hrU093QkJsMUVocUl3VkR3T2llZzJKTUdsMEVYc1BaZmtOWkktSFU0b01paS1Uck5MelJXa01tTHZtMDloTDV6b3NVTkExNXZlQ0twaDJXcG1TbTJTNjFuRGhIN2dMRW95bURuVEVqUFk1QW9oMmluSS0zNlJHWVZNVVViTzQ2Q3JOVVl1SW9iT2lYbEx6QklodUlDcGZWZHhUX3g3c3RLWDVDOUJmTVRCNEdrT0hQNWNVdjdOejFkRGhJUHU4PSJ9fQ.eyJpc3MiOiJjb20uaWJtLm1mcCIsInN1YiI6IjM1NDcyYWNhLWVlNmItNGNhZi04OGQ2LWQxY2ExNjQ0NzM4NyIsImF1ZCI6ImNvbS5pYm0ubWZwIiwiZXhwIjoxNDgwMzM5OTU0NjE2LCJzY29wZSI6ImFvdkxvZ2luIn0.JSm3nrW6BD5i66GossHYM4-6GqQfC-ZSH5P-X4M9mws2jBNvCkFKgv_XbRAb3km-0NMZz3FHsrY_0h0dx7fpJYiR9CIjaY-PFw75zdKbyEpzbhAX7OjZtYOtZblKEYLkT8mH-0mLc6VE_YBPFd2q55HMmECCLirAAdWwzMGgEzL02OKTd1GVuJyjqjlxeOJypFglaHezuByd6eGVMFJvnfDX3h_o6k8sWcv-g7UFa8jtcMNZpbzFOYG9Q2nGQ-oYIt17QyF4CVKPMN4anMwRRQ_2cjuvg-1ZuU450hxBX3u09wBxJ21mQklgg72t7fdLKgT7EIPmQlPP3wrX9qzy7A
HTTP/1.1 200 OK
Update:
The HTTP 401 and 403 calls to the external resource and serveral calls to MFP can be avoided if the scope is send in WLResourceRequest
It generates a new token calling an external resource using an absolute URL but also calling a standard protected adapter using a relative URL
Sample calling a protected adapter:
var resourceRequest = new WLResourceRequest(
"/adapters/AOS42_AOV_API/resource/protectedResource",
WLResourceRequest.GET,
{'scope' : 'aovLogin'} // it avoids 401 and 403 responses
);
resourceRequest.send().then(
function (response) {
alert("response ok protectedResource " + response.responseText);
},
function (response) {
alert("response ko protectedResource " + response.responseText);
}
);
Sample calling an external resource:
var resourceRequest = new WLResourceRequest(
"https://someurl.com/someApp/protectedResource",
WLResourceRequest.GET,
{'scope' : 'aovLogin'} // it avoids 401 and 403 responses
);
Update 2:
We've made a change: Instead of calling to a protected external resource, receiving HTTP 401 and then sending the challenge, now we call to WLAuthorizationManager.login before.
In Android, it continues calling MFP 3 times before each call, but now the server returns the same Bearer Token.
The same Cordova Application calling the same Rest API protected by MFP and using the same security adapter in MFP works perfectly fine in iOS.
Once the bearer is obtained, we see only calls to the external API.

Answer 1

This bug has been resolved in a just-released iFix for MobileFirst Foundation 8.0. The build number is 8.0.0.0-IF20170125-0919. Please login to IBM Fix Central to download the iFix.
The associated APAR is:
PI74988 MULTIPLE AUTHORIZATION CALLS ARE MADE FOR EACH REST CALL IN ANDROID APPLICATION
Since you're using Cordova, I believe updating the cordova-plugin-mfp plug-in to #8.0.2017012210 should suffice.