Plugin authentication not automatically completing when refreshed after a delay

Question

I’ve built a plugin for Banno Mobile & Online and I’ve got the OAuth authentication working in nearly every case. In part of the normal use of the mobile app, however, the user sometimes encounters the Banno SSO login screen prompting them to enter their username and password, despite already being logged into the platform. This is happening when the application has been open for roughly 10+ minutes. I've also noticed that this only happens with some actions that would refresh the dashboard where the plugin is displayed. I've separated the actions into three categories based on their behavior:

1. Does not cause reload of plugin:

   • dragging the screen down/'refresh' the dashboard gesture
   • pause app and reopen
   • lock/unlock phone

2. Reloads plugin with URL provided by plugin settings

   • navigate off of dashboard using sidebar menu ('hamburger' icon) and back
   • log out and back in
   • close app entirely

3. Reloads plugin using a previously loaded URL

   • rotate screen horizontally/vertically
   • selecting a dashboard item (e.g. a transfer) and then 'back' navigating to the dashboard

Actions in type 2 will successfully load the plugin regardless of how much time has passed since the app was opened. However, type 3 is more complicated. It appears to re-using whatever URL it 'ended up' at after the first time it was fully authenticated. For example, when it is first loaded (having completed authentication), it will 'end up' at a URL that contains auth code A. If it is reloaded with a type 3 action, the app will send a request to the URL containing code A. By OAuth design it will fail to authenticate, and our plugin will re-initialize the authentication process - ultimately redirecting to a new URL with auth code B. If it is again refreshed by a type 3 action, the app will still send a request to the URL that contains auth code A rather than the most recently used URL with auth code B. It appears that no matter how many times a type 3 refresh is performed and the plugin creates new redirects, the app will still be using the URL that it 'ended up' at the first time it was loaded.

This circumstance would still result in a successful authentication of the plugin, but the current issue is that a type 3 refresh will not be able to complete the re-authentication after a certain time frame. As described above, after roughly 10+ minutes, when redirected to the authentication server the app will not automatically authenticate the user and will instead leave the Banno login screen sitting inside of the plugin window.

The only solution I can think of to work around this problem is to ensure that the initial authentication 'ends up' at a URL that can be used to display the content of the plugin indefinitely. This would mean establishing a separate system to validate that the request coming from the app after a type 3 action is a valid request to display customer information. Any suggestions for how to handle this situation would be appreciated.

Answer 1

Plugins in Banno Apps are embedded web applications. In Banno Online, this is an iframe and in Banno Mobile this is an embedded webview. While there are slight differences in these two scenarios, the problem you are describing remains the same.

The plugin page can be refreshed at any time. There's no way to prevent this behavior. A well written plugin will keep its state between these refreshes so that the user does not even notice.

Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.

Since the authentication used for the initial OAuth handoff expires after a timeframe, any further attempts to utilize the OAuth flow at that point would indeed show the user the login page. By keeping a session in your app, with its own distinct timeout and by extending that timeout with user activity, this scenario will very rarely occur.

You will have to decide how long your authentication cookie is good for. It might be worth it to detect that your authentication cookie is expired and display a special error page to the user asking them to reload the app.

The only solution I can think of to work around this problem is to ensure that the initial authentication 'ends up' at a URL that can be used to display the content of the plugin indefinitely. This would mean establishing a separate system to validate that the request coming from the app after a type 3 action is a valid request to display customer information.

You are exactly correct here. The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.

Answer 2

Some clarifications on the scenarios above:

1. Is this specific to Android, iOS, or does it occur for both?

2. Is it possible to reproduce the behavior using https://github.com/Banno/simple-plugin-example? (even if that requires modifications...seeing the code that reproduces the behavior would be helpful for Engineering.)