Creating a session ID (sid) cookie for a mobile app

Hey smart people,
We have a scenario where a native mobile app using auth code with pkce needs to pop a browser webview and get SSO to an Okta protected SAML web app.

When we get access / ID tokens via api call to /tokens using the refresh token, we get a blank sid cookie.

There’s a sid claim in the id token. Could we fabricate a Sid cookie with that and inject it into the webview?

Any other suggestions which avoid the user having to do primary auth? We’re on Okta classic.

Cheers,
Adrian

Anyone tried to build a session retrival API using the sid from the identity token? Any success?

Webview behaves closer to a sandbox VM, and ideally the Android webview doesn’t do well / errors out when there is external modifications - This may need a POC with the android sample, however we don’t have an out of the box version that can help.

Thanks @krishna we’re trying to POC at the moment with postman to see what comes back from different calls.

Should the sid in the is token be of use here? Any other ideas?

To Quote our SSO by using native applications doc -

SSO between browser-based web applications is achieved by sharing cookies. Unlike web applications, native applications can’t use web cookies.

So cookie injection is something I haven’t tried to confirm if this can work with your use case. Ideally, since session cookies aren’t injectable, this can’t be supported. I will check with the team if there is any other way.

Thanks! Really appreciate it.

The other thing we were wondering is if we could do an exchange of an access token for a SAML token to send to the SP.

All ideas are on the table (except forcing the user to re-authenticate)

Cheers
Adrian

This email is confidential. The information communicated in it is intended only for the person to whom it is addressed. If you are not the intended recipient, please immediately notify the sender and delete the information and you must not review, disclose, use or rely on the information. CAUTION: This email, links and files included in its transmission by IdentityXP Pty Ltd ABN 91 653 323 052 are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us immediately and delete it without reading or copying the contents contained within. IdentityXP does not accept liability for the views expressed within or the consequences of any computer malware that may be transmitted with this email. The contents are also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner.

Could you open a case with Okta’s official support? This may need more insight from other members.

I can give it a go … this tends to be a bit outside of Support’s skill set and they usually just direct folks back to the forums for devvy issues.

Hi @krishna did you have any luck by any chance? We’ve also raised a case with support.