1

I’ve built a plugin for Banno Mobile & Online and I’ve got the OAuth authentication working as described in the documentation. It follows the same structure as the simple plugin example, so it automatically initializes the authentication process when the page is reached without an auth code or state. When it is reached with an auth code and state in the url, it uses them (along with the code verifier stored server-side) to retrieve the identity token. The plugin also has a primary action button that links to an information page at a completely different address.

The plugin is successfully completing authentication and retrieving an identity token in all cases except for one. In the Android version of the Banno Mobile platform, when the user clicks on the action button, it opens the link in a new window as expected – but when the user closes the window and returns to the application, the plugin is reloaded with the previously used auth code in the url. As the plugin is designed, it tries to use the auth code to retrieve the identity token, which fails since it was previously used.

Is there something besides the url that my plugin should be looking at to determine how to handle the authentication flow? This issue is not happening anywhere in the iOS or browser versions of the Banno platform, so this appears to be the only use case where the plugin wouldn’t be expected to fully reinitialize its authentication.

Elijah Chisholm
  • 11
  • 2
  • Have you found a solution? Your description matches our problem to a T. – Ravindra Dec 23 '21 at 14:05
  • 1
    I changed the logic that occurs when authentication fails to re-initialize the authentication process. This works for our system since we are considering re-initializing an appropriate response to any case that would cause a failed authentication anyway. This solution doesn't modify the URL or redirect to an entirely new address, but rather redirects to the OAuth server with a new code as per the first part of an OAuth flow. – Elijah Chisholm Dec 24 '21 at 21:45
  • I seem to have no indication in our plugin server code, about the failed authentication, to handle it, in the Android case. The control never comes back to any of the redirect URIs, unlike the browser case, where the control does come back on returning to the application. The control never comes back even in the case of iOS, but plugin displays OK always. – Ravindra Jan 04 '22 at 15:33

1 Answers1

0

In a native mobile app, the plugins are rendered in a webview. As the app changes state, those webviews can be re-initialized. This will cause the webview to "reload" the page with the full URL.

Of particular importance is that your plugin is designed to handle these reloads gracefully. One of the common issues is leaving an OAuth2 code in the URL which will cause problems. OAuth2 codes are only able to be exchanged one time for an access token. If the page reloads with the code still present in the url, your app is likely to attempt to re-exchange that already used code and an error will occur.

Chad Killingsworth
  • 14,360
  • 2
  • 34
  • 57
  • I had tried redirecting to a URL that doesn't contain an Authorization Code after the authentication flow has been completed. Rendering is now done in that redirect URL that has no OAuth parameters. But it did not help to resolve the issue. – Ravindra Dec 23 '21 at 14:24
  • I have implemented a redirect when the plugin is reached with an invalid auth code. I am now having issues with a new problem where the user's credentials are not being automatically provided to the OAuth redirect when the app has been open for 10+ minutes. The result is that the user is presented with a login screen within the plugin window. The steps to reproduce this are: 1. Log in to the app and land on the dashboard. 2. Wait ~10 minutes. 3. Rotate the screen or do some other action that causes the plugin to be reloaded. – Elijah Chisholm Jan 25 '22 at 16:02