title: Plugin authentication not automatically completing when refreshed after a delay
body: <p>I’ve built a plugin for Banno Mobile &amp; 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:</p>
  <ol>
  <li><p>Does not cause reload of plugin:</p>
  <ul>
  <li>dragging the screen down/'refresh' the dashboard gesture</li>
  <li>pause app and reopen</li>
  <li>lock/unlock phone</li>
  </ul>
  </li>
  <li><p>Reloads plugin with URL provided by plugin settings</p>
  <ul>
  <li>navigate off of dashboard using sidebar menu ('hamburger' icon) and back</li>
  <li>log out and back in</li>
  <li>close app entirely</li>
  </ul>
  </li>
  <li><p>Reloads plugin using a previously loaded URL</p>
  <ul>
  <li>rotate screen horizontally/vertically</li>
  <li>selecting a dashboard item (e.g. a transfer)  and then 'back' navigating to the dashboard</li>
  </ul>
  </li>
  </ol>
  <p>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.</p>
  <p>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.</p>
  <p>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.</p>