Session Handover via OpenID Connect between a Mobile Application and a Website?

Question

I am trying to assess secure ways to implement a session handover between an app and a website in the same company ecosystem.

The Setup

Mobile Application A and Website B use the same company OpenID Connect (OIDC) provider to login their users independently from each other with completely separate session handling. Single-Sing-On (SSO) is supported by the provider.

Now App A wants to seamlessly handover the user to Website B to continue his/her business flow.

While this is normally a run-off-the-mill SSO setup, the issue arises, because App A keeps it's own session states independent from the device's browser. (It can even switch between previously authenticated users without re-authentication with the SSO provider.)
i.e. When the App A hands over the user to the Website B, the browser session is probably not signed-in any more to the SSO provider, causing a login prompt. This shall not happen, though.

The proposed workaround

It is now proposed that App A should pass the IDToken of the user to Website B.
Website B is now expected to take this IDToken and log-in the user with it seamlessly.
i.e. The login should work independently from an existing SSO session in the browser just by trusting the IDToken.

Website B can validate the IDToken and it's Signature against the OIDC Provider.

Ideas?

While this is technically possible I have my doubts that this is a particularly good idea.
I have a hunch that this might lead to some security holes. E.g. When a man in the middle intercepts the IDToken.

I am not even sure it is a good idea to pass on the IDToken to other services in the first place (Even though they reside in the same company and want to hand-over user sessions to each other).

Do you know of any established seamless handover flows between an app and a browser website that are considered safe?
Or maybe there is a common way to seamlessly create an SSO session just based on the passed IDToken?

Thanks!

Answer 1

Correct, a token can be used to hand the user's state from the app to the browser, somewhat independently from your authentication system. Specifically:

• The app should store the relevant state on the server. In particular, this would involve storing information about the current session. The server returns a time-limited, cryptographically secure token that can be used at most once (a nonce). For example:

  > POST /save-state
  >
  > {...}
  
  < 200 OK
  <
  < {"resume-url": "https://example.com/resume?token=XyuxgTXSSDaXei342ZD0mg"}
  

• The app opens the device's browser to open that URL. The server retrieves the stored state and does whatever is necessary to restore this state in the browser. For example, this could involve setting cookies or updating LocalStorage. Once done, the user is redirected to the actual page that the app wants the user to see.

  > GET https://example.com/resume?token=XyuxgTXSSDaXei342ZD0mg
  
  < 200 OK
  < Set-Cookie: ...
  < Content-Type: text/html
  <
  < <script>restoreState();</script>
  

However, the app should not hand off its own session token. Instead, it should cause the server to generate a new session for the browser. This is useful so that you can display an accurate list of active sessions and to terminate the sessions in a more granular fashion. In particular, logging out in the browser should not cause the app's session to be terminated.

OpenID may not be quite relevant in this context, but that depends on how you use it. OpenID is a proof of identity by an external service for your account management system. The external identity provider does not create a token that you should use directly as a session identifier for the communication with your server. Instead, you would use the external service's authentication as a prerequisite for issuing your own token on your backend server.

There should not be MITM concerns in this kind of design. There are three channels where the sensitive token is transmitted:

• from the server to the app: not a problem because you use HTTPS, right?
• from the app to the browser: security depends on the operating system, but if the user's system is compromised you can't trust the app or the browser anyway
• from the browser to the server: not a problem because you use HTTPS, right?

This assumes that your web app and your mobile app are frontends for the same server, and that OIDC is performed between the server and the external OpenID provider. But if the mobile app and your server manage identity separately, then transferring the OIDC ID Token from the app to the server would indeed be problematic. While this is perfectly fine from the perspective of your app, this would not allow the OpenID provider to distinguish between these sessions and you would have to decide whether your server or your app get to refresh tokens. In some cases it may be desirable to relay all relevant operations in your web frontend back through the mobile app, so that the app alone contains a OIDC ID token. But this would require that the mobile app is always running in the background while the web app is in use, which might be a problem especially for memory-constrained mobile devices.