Can I use the Okta Sign-In Widget, OIDC and normal Okta session functionality?

[richard]

The primary use case is that the widget would be used to get an id_token and then it would be passed to a downstream app (App A) which would consume it and SSO the user and issue an app session token of their own.

In addition, a link within App A would then trigger an SP-initiated SAML flow to another downstream app (App B). As App B can’t consume an id_token, we would need to exchange it during initial Okta auth (I would think) for an Okta session cookie. I’m relatively clear on using the following approach to do so. However, can we do the same in the Okta Sign-In Widget?

That primary rationale is to avoid having to re-invent the wheel and reuse the widget for as much as we can.

Cheers.

[tom]

You shouldn’t be passing an id_token around applications. id_tokens are usually bound to the application (client) that asked for an id_token. An okta session is created when using OpenID Connect, so you could have additional applications make a round trip to Okta to do SSO, regardless of the protocol.

If I understand your question, I believe the answer is yes!

Let me know if you need any clarification though!

[richard]

Hi Tom,

Thanks for your response. In this scenario, App A would host both the app itself and the sign-in widget so we wouldn’t pass the id_token to App B or others in this scenario.

In terms of the widget config, my thinking is we would need to configure the widget using the authParams.display: 'page' and authParams.responseType: 'id_token'. Based on my initial testing, the following results in:

1. An id_token be returned to the sign in Widget
2. An Okta session cookie being set on redirect.

    oktaSignIn.renderEl({ el: '#okta-login-container' },
        function success(res) {
            if (res.status === 'SUCCESS') {
                console.log("success");
                oktaSignIn.token.parseTokensFromUrl(
                    function success(res) {
                        console.log("success.parseTokensFromUrl.success");
                        oktaSignIn.tokenManager.add('my_id_token', res);
                        res.session.setCookieAndRedirect(redirectUrl);
                    },
                    function error(err) {
                        console.log("success.parseTokensFromUrl.error");
                        handleError(err);
                    }
                );
            }
            return;
        }
    );

That would seem to tick both boxes in terms of issuing and id_token and subsequently being able to access a SAML app integration without being prompted again to authenticate to Okta (as we already have a session, as defined by the cookie). Is that an accurate assumption?

[tom]

Your assumption is accurate. Let me know if you have any issues getting set up!

[richard]

Thanks, Tom. Will do.