I have a test application that accesses two Adapters:
- A Java adapter with a method protected by an OAuth scope corresponding to that same realm.
If I follow this sequence everything works as expected:
- Attempt to access the JS adapter, I get challenged, authenticate, get data.
- WL.Client.isUserAuthenticated() and WL.Client.getUserInfo() now behave as expected
- Logout using WL.Client.logout()
- WL.Client.isUserAuthenticated() now shows I'm not authenticated
- A second attempt to access the JS adapter causes another Challenge, as expeccted.
However, with the Java Adapter logout() seems not to behave as expected.
- Starting with no session, attempt to access the Java adapter, the challenge happens as expected and I get to my data
- I can now access the JS adapter without further challenge and the WL.Client.getUserInfo() calls gives the expected results.
- WL.Client.logout() appears to work, in that WL.Client.isUserAuthenticated() now shows I'm not authenticated
- But a call to the Java adapter still works without further challenge
- A call to the JS adapter does result in a challenge
If I'm running in my browser simulator environment I can destroy the OAuth session by using this command:
The question is:
Should the WL.Client.logout() method have destroyed the OAuth session? If not what API should I be using?
Best How To :
With OAuth, logout 'works' differently. See the following user documentation topic (search for "logout"): http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_model.html?lang=en
The login/logout API:
The WLClient login/logout API enables a user to log in to and log out of a specific realm, by updating the server side security state. However, in the new OAuth-based security model, security credentials are also kept in the access token on the client side. The result is that using this API will cause an inconsistent state, for example, in which the client is logged out of a realm on the server side but still holds a valid token for that realm on the client side. To solve this inconsistency, it is recommended to re-obtain the access token, by using the obtainAuthorizationHeaderForScope method, after successful login or logout.
For example, consider a client that passed the security checks for Realm1 and Realm2, and later calls logout(Realm2). In this case, the access token on the client would still contain the security credentials for both Realm1 and Realm2, and the client could use this token to access protected resources. To refresh the token, that is, to obtain a token for Realm1 only, the client calls obtainAuthorizationHeaderForScope without the logged out realm Realm2.