Okta Widget Issues with Session.Get

Hello,

My company is migrating our authentication system to Okta, and I’m in charge of a SPA (angular).

We are having an issue while trying to verify if the user is already authenticated in the system. The verification process is through a call to the method securityWidget.session.get, but this call is returning an error if the Third party cookies are disabled in the browser( Safari by default).

Error: {
   "errorCode":"E0000007",
   "errorSummary":"Not found: Resource not found: me (Session)",
   "errorLink":"E0000007",
   "errorId":"oaegLKbsDwSTyq7LjprGCxftQ",
   "errorCauses":[

   ]
}

Could you please help me to find an approach to avoid this issue?

Our process is simple, we want to use the Widget to sign in, get the access token. Share this access token with every call to our API, so our API can verify the access.
We also want to keep the token alive in our client while the customer is using the application, even if the page is closed and the customer came back before the session expire.

Is there any recommendation? I was reading several forums and I cant find a working solution with the Third Party Cookies disabled.

Thank you for your time!

We’ve been investigating this as well. The cookies aren’t really “third party”, but since they are saved on the Okta domain it looks like they are as far as Safari is concerned. A simple (but not so elegant) solution is to enable third party cookies in Safari.

How are you performing the initial login?

Hi Nate,

Thaks for your reply.

Enabling the third party cookies isn’t an option because is a public face application, and we don’t want to ask IOS customers to perform this action on their devices.
We are able to reproduce the same issue in chrome if the third party cookies are disabled to( by default chrome allows third party cookies).

The initial login is performed through the basic Okta Widget.
using the following configuration:

authParams: {
display: ‘popup’,
responseType: ‘id_token’,
responseMode: ‘okta_post_message’,
scope: ‘openid,email,profile,address,phone’
},

On Login Success we are saving the the security token.

On Page Init we are calling session.get to see if the current session is active.
If the session is active we are proceeding.
if the session is invalid we are showing the Login page.

Thank you!

Makes sense, thanks for the info.

Browsers that restrict third-party cookies will have problems with display: popup, because the widget uses an iframe to save a cookie on an Okta domain without actually redirecting the whole browser to that page.

You have two options to work around this:

  • Set up a custom URL domain so the login domain is the same as your SPA’s domain. For example, if your spa is on app.example.com, make the Okta domain id.example.com and the Okta session cookie will no longer be considered a third-party cookie.
  • Use display: page and the implicit flow to do login via a full-page redirect. Browsers (Safari especially) are more accepting of third-party cookies if the browser actually visits the third-party domain to log in.

Hope this helps. Let me know if you need more guidance!

Hi Nate,
I was able to find a solution using the approach that you suggested.
The final solution was as follows:

Client Side ( Angular )

  1. Login using the widget with the following configuration:
    authParams: {
    display: ‘popup’,
    responseType: ‘code’,
    responseMode: ‘query’,
    scope: ‘openid,email,profile,address,phone, offline_access’
    }
  2. If login is successful, get the returned code and:
    2.1 Call the API service to exchange the code by tokens.
  3. Call an API endpoint to refresh the token before the expiration.

Server Side(calls to the Okta token endpoint were implemented in the API for security purposes)

  1. Method to Exchange the "code for the Tokens(id_token, access_token, refresh_token) using the implicit flow. This code was implemented in the API in order to keep the Client Secret in a safe place.
    1.2. Return the tokens to the client, and store this information in the local storage.
  2. Method to refresh token.

Thank you for your help.