We have two apps, App A and App B. I'm working on a POC for connecting the apps to each other.
For background, IT wants to use Okta in some fashion. My experience with Okta has always been as the IDP and SSO was done via a normal SAML or OIDC workflow. But this requires the user to know about Okta and log into Okta. This setup is suitable for companies who are managing their users through Okta.
The UX that we are looking for involves a user with a fresh browser (no cookies anywhere) logging into App A, and then being able to click a link in App A and ending up in App B authenticated, without ever having to see an Okta page (a redirect through an Okta URL would be OK, however). We would also like to support the opposite (App B sending the user, authenticated, to App A). There is a shared convention between the apps that the email address of the user will be the same on both sides.
Obviously we could create some form of SSO directly between these apps, but IT wants to manage whatever authentication connection we use in Okta (for security, etc.).
Without knowing the direction to go my instinct tells me that we will need to use Okta as an IDP, but that we will need to use an Okta SCIM API of some kind to register users in Okta, at some point before we send them from App A to App B. Is this correct? If so, is it also possible to authenticate the user so that they don't have to log into Okta in order to arrive authenticated at App B? Is this completely wrong? Would that basically require us to make App A and App B both identity providers and consumers? Or is there some kind of better / simpler workflow for this scenario?
You can do Okta sign-in w/o redirects to Okta, if you are using Okta widget or Okta APIs. Then you don't need to show any Okta UI to your users. Only one thing, make sure that Okta cookies are sent with those requests, so that Okta knows that you already have a session.