I am trying to assess the security implications for 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.


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 a SSO session just based on the passed IDToken?


1 Answer 1


I'll take a run at this but I'm not an expert in mobile matters, so here's my two cents:

  1. It's never a good idea to mix 2 different flows by handing over session information just because they have quite a bit of different attack vectors etc. ...

  2. From your description it mainly depends on how you mean by "handing over to the website". Are you redirecting the user to a link on the default browser of the mobile phone or are you opening a webview etc and loading your website on it. Based on this you will different attack surfaces and vectors to deal with.

  3. Let's say you deal with the first 2 points and you're good with it. Now, it depends on what "business" is the user continuing. If it's related to payments or something else business critical, making the user sign in is actually good so that sensitive actions are password gated and session is locked down to the website and for the action.

  4. Passing in the mobile session is definitely bad, because your ID token should be isolated to the device and other variables so you can identify and isolate on the Backend and apply different rules for WAF, RASP, logs etc etc ....

  5. Given your scenario, one thing you can probably do, is to use the "impersonation" OAuth flow to receive a token with very limited scope, timeout and other controls to continue non-critical business on the website. But user would need to login and handle all the invalidations etc when the new sessions are created, to do anything critical.

But it all depends on the circumstances...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .