Comment 1 for bug 1347771

I need to investigate this a bit, just to make sure that everything is fine on our side, but here is how the flow should go, supposing that the password has been changed remotely:

1) the app (for instance the U1 store app) asks OA to authenticate against U1
2) OA (signond) defers the job to the U1 authentication plugin

Now, if the U1 plugin can detect that the password is no longer valid:

3) The U1 plugin emits a userActionRequired() signal; control switches to OA
4) OA gets the new password from the user, and returns it to the U1 plugin
5) the U1 plugin responds with the new authentication tokens

If the U1 plugin cannot detect that the password:

3) The U1 plugin returns an invalid token to the app
4) When the app tries to use some U1 APIs, it gets an error which clearly indicates that the token is invalid
5) The app tells to the U1 plugin (via OA) that the token is invalid. This can be done by adding a specific mechanism to the plugin, or by passing some parameter to the session data.
6) The U1 plugin emits a userActionRequired() signal; control switches to OA
7) OA gets the new password from the user, and returns it to the U1 plugin
8) the U1 plugin responds with the new authentication tokens