Okta-react 5.1.2 + okta-auth-js 5.0.2, okta sign in widget, typescript

Questions
1

Apologize if this is already been mentioned.

I’m having an issue with type resolutions using this latest versions of the two libraries on the “Security” component as part of okta-react.

  1. It appears that the “OktaAuth” component created by the okta-auth-js doesn’t appear to be compatible with this version of the okta-react “Security” component. I get the following: “Type ‘OktaAuth’ is not assignable to type ‘OktaAuthBrowser’.”

  2. I also can’t seem to create a function that aligns with what okta-react wants for the “restoreOriginalUri”. I get the following: “Type ‘(_oktaAuth: OktaAuth, originalUri: string) => Promise’ is not assignable to type ‘RestoreOriginalUriFunction’.”

My setup is quite simple and from the most recent example I could find:

1
1889×603 32.4 KB

2
2712×204 14.1 KB

Questions/requests are:

  1. how do I get the above working?
  2. how do I implement the new service based approach for token renewal?
  3. is there a working example for this version combination of modules?
  4. is the okta sign in widget worth it as it always seems behind the product as far as features? does the latest version of it now support password-less logins?

I just want to do this correctly. Can someone who is much smarter than me help me out here? The online documentation seems to lack a fully implemented example using these new versions.

Thanks in advance!

2

To follow up with more information, the useOktaAuth() hook destructures a OktaAuthBrowser. In the given examples, I’m not sure that will work. Do I move the creation of the OktaAuth upstream to the App.jsx?

3

Hey Dean,

From what I can see, I don’t see anything wrong with your code, and this is most likely a compatibility issues between the two versions.

Use the following to pair the two libraries:

  • okta-auth-js 5.0.2 <-> okta-react v6+ (which is currently not publish, but stable on Github)
  • okta-react v5.1.2 <-> okta-auth-js ^v4.8.0 (below v5)

Once you update those libraries, you shouldn’t have any type issues.

In regards to your other questions, I’ll try to best answer it from my unofficial, personal opinion :slight_smile: .

1. How do I get the above working?
Update the versions to compatible counter-parts

2. How do I implement the new service based approach for token renewal?
You just need to run the service on the OktaAuth instance. I would probably run it prior to passing it into the props (whether that is done upstream in App.jsx, or in your SecureSwitch.jsx).

Docs: GitHub - okta/okta-auth-js: The official js wrapper around Okta's auth API

3. Is there a working example for this version combination of modules?
Not for these versions, but here is an official example for okta-react v5.1 and auth-js v.4.8: samples-js-react/custom-login at master · okta/samples-js-react · GitHub

In addition, if you ever need the most recent example, you can probably refer to the e2e build: okta-react/test/e2e/harness at master · okta/okta-react · GitHub

4. Is the okta sign in widget worth it as it always seems behind the product as far as features? does the latest version of it now support password-less logins?
This comes down to your development resources and time to market. I think you’ll be hard-pressed to capture all the potential edge-cases in your sign in flow or keep up with the features. One of the benefits of the SIW is being able to just toggle a feature in the admin console, and having that available on the front-end with just a configuration change.

However, if your application requires a more customized sign in flow, you might find it difficult shape the SIW.

In terms of features, the SIW is probably the most actively developed library, seeing updates and fixes on a weekly basis. For reference, since last June, there has been 60 releases.

For passwordless, you’ll need “features.passwordlessAuth” in the configuration.

5. Do I move the creation of the OktaAuth upstream to the App.jsx?
Shouldn’t matter from a technical perspective, all on your depends on your code and organization style.

Hope you find this helpful, feel free to ask me anything else.

1 Like
4

Also, once okta-react v6 is fully publish, you won’t need to start/stop the oktaAuth service.

1 Like
5

@brh55, When is 6 supposed to drop?

6

@brh55, thanks again for answering these questions. you are a rockstar!

If I chose to abandon the SIW and go hosted, do the tokens auto renew? I had problems with older iterations of hosted that basically the session went stale and didn’t send us back to a login page. The widget seemed to fix that issue. Is there a technique to prevent that situation from happening using hosted?

7

Unsure when it will be officially published on npm, but the version 6 is available on Github if you want to try and utilize it today.

8

If I chose to abandon the SIW and go hosted, do the tokens auto renew? I had problems with older iterations of hosted that basically the session went stale and didn’t send us back to a login page. The widget seemed to fix that issue. Is there a technique to prevent that situation from happening using hosted?

Either hosted or SIW (Okta deployment models - redirect vs. embedded | Okta Developer), you’ll still need to manage the tokens and session within your application (use okta-auth-js).

If you look at the hosted-login react sample - https://github.com/okta/samples-js-react/tree/master/okta-hosted-login. You’ll see in the navbar, there is a check with authState.isAuthenticated() to present appropriate options based on if the user is logged in or not.

Now if you are also accounting for the cookies sessions within Okta - usually for SSO, you’ll also want to update your checks to include a session validation within Okta.

9

@brh55 Do you need to do this even under the SecureRoute component? Does that have that type of authentication checks built in? The example shows that those checks are still being done, but what is the value of the SecureRoute then? Should we build isAuthenticatied checks into every secured (SecureRoute) component we build to redirect them back to the login screen?

10

Oh yes, SecureRoute does perform these checks when the user hits a protected view. But it does not check if the session (Sessions | Okta Developer) is stale as by default it only checks if there are unexpired tokens present.

1 Like
11

Thanks again Brandon!

Sorry, one last question about the secure routes, do any child routes routes defined under a secure route need to be also a secure route? For example, if I want to secure the whole site, I define a “/” route using the secure router.

image
image842×395 22.3 KB

would any routes defined later (say as a menu option) also need to be defined as a secure route or will it inherit the benefits of the parent route?

image
image924×385 17.7 KB

and would this type of check satisfy the session and auth checks you are talking about:

image
image728×387 15.4 KB

(hopefully this should quench my knowledge gathering thurst for now…)

12

The nested/child routes should be secured from the parent SecureRoute as it’s just a component that checks if authState.isAuthenticated, if so it returns a normal route with props passed along.

For the second part, if you require the Okta session to be valid, you can leverage the transformAuthState (GitHub - okta/okta-auth-js: The official js wrapper around Okta's auth API) to update the authState prior to emitting and storing.

Can you help me understand what are you currently attempting to solve around session logic:
Are you trying to check if there is an active session if the user is already logged in to the Okta instance?
Are you trying to keep the users session active within Okta as they are using the app?

13

Goal here is: If the session expires, on any action taken on any child component of a secure route, I want that to kick the logged in user back to the login screen if it is under a secured route either on the next click on any component (parent or child) or automatically.

In my experience, a child component 2 levels deep from the one directly referenced to the secure route may not cause that to happen. For example, if that child component tries to leverage the access token to talk to an okta secured web service, it can fail and cause application failures instead of taking the user back to the login page due to the fact that the session or token is invalid.

It seems that the okta sign in widget seemed to employ something that watches session and kicks back to login when it expires automatically without user intervention. This is something the hosted login doesn’t seem to do.

To be honest, I may have used a version of these libraries that had a bug or perhaps a failure in my implementation. We use hooks and not class based React, so maybe I’m doing something wrong and would like to do this correctly.

Correct me if I’m wrong: React updates its state and functional components based on dependencies. If a child component gets updated, the parent components don’t necessarily get updated. If I have a child component two components deep that gets data from that okta secured web service as described above, or a user just doing some navigation at the child level, it will allow it until either the user logs off and logs back in or the session is programmatically refreshed.

14

I’m going to guess your suggestion with the “transformAuthState” will do the trick to solve my problem? I assume that the SecureRoute uses this to validate the route?

15

@dean.dot.okta v6 of the Okta-react just became published on npm.

16

It seems that the okta sign in widget seemed to employ something that watches session and kicks back to login when it expires automatically without user intervention. This is something the hosted login doesn’t seem to do.

The hosted login is the latest sign-in-widget just managed and hosted by Okta with some additional utilities built in (Okta deployment models - redirect vs. embedded | Okta Developer). You do this by redirecting the user to the okta hosted → user logins → redirect to callback to process code and tokens. Once the user is back onto your application, you still need to manage session and token state.

You can think of the sign-in-widget is it’s own isolated application, underneath the hood it has okta-auth-js as it’s authClient. When we are embedding it within our react application, our application authClient has no idea what’s happening within the widget unless we want to persist those tokens to our client (you’ll notice a onSuccess callback, where we typically pass along these tokens) or our callback route is provided tokens and an auth code (Sign users in to your SPA using the redirect model | Okta Developer)

I think for the complexity of your application, you may find value in implementing a state management library like redux.

18

I think I have done it, integrated the latest. I left and came back overnight for the last two nights (left the application logged in) and this message appeared in the browser:

AuthSdkError: Could not load PKCE codeVerifier from storage. This may indicate the auth flow has already completed or multiple auth flows are executing concurrently.

I would have expected it to take it back to login at this point. Looks like this occurs in the callback somewhere. How can I fix this?

I think this thread shows that this is an consistent issue in React v6.0.0, but it doesn’t appear to be solved yet.

I’ll be honest, I’m having difficulty finding a combination of what versions will be stable. I know v6.0.0 says stable, but hitting this error right out of the gate and so are others. When can an update to the issue be available.