Okta SignIn Widget and Refresh Tokens

[rclark]

Hi,
I am using the Okta SignIn Widget on my Web App, and I receive an access token which I then send to my backend server and verify using the Java Jwt Verifier (AccessTokenVerifier).

This all appears to be working fine, but how do I manage the Expiration time of the token? I would the expiration time to be reset while the user is active on the site, and not timeout after the preset time.
If I configure the user to have a 30min (or 2 hour) expiration time, what happens when that token expires? Do I need to use a Refresh Token? I cannot seem to get a refresh token from the SignIn Widget, and I cannot find what to do with it, if I were to receive one.

[phi1ipp]

if you use widget, you can rely on underlying auth-js library for refreshing the access token. You only need to get subscribed to the token expiration event and request a new one in its callback. Read about tokenManager - https://github.com/okta/okta-auth-js#the-tokenmanager

Also, if you have a backend, can’t you establish a session cookie with it instead of using access token from Okta?

[rclark]

Thanks for the reply @phi1ipp

I do have an existing JSP servlet backend that has session management already that I could establish a session cookie with. Are you suggesting I do this with the Okta session management API, or the existing session management that is in place?
I also need to SSO to another application that is using Okta, but we do not have any control over that application. Would using a session cookie make this more difficult or easier, or no affect?

[phi1ipp]

@rclark

I do have an existing JSP servlet backend that has session management already that I could establish a session cookie with. Are you suggesting I do this with the Okta session management API, or the existing session management that is in place?

If it’s your backend then you can have your own session based on initial id/access token received from Okta.

@rclark

I also need to SSO to another application that is using Okta, but we do not have any control over that application. Would using a session cookie make this more difficult or easier, or no affect?

I’m almost sure that Okta session cookie will guarantee you signing into the second application w/o re-authenticating your users (unless there is a special policy for the application)

[rclark]

Thanks again fro your help @phi1ipp. It is really appreciated.

Using the SignIn Widget, how can I get the session cookie, and set it on the current server session? I am rather confused by this part.

I am currently using oktaSignIn.hasToeknsInUrl() and parsing the access and id tokens, and then passing those to my server for verification using the JwtVerifier. I can see that it sets two attributes on the session, okta-oauth-nonce and okta-oauth-state, but I cannot find any documentation that tells me what those are used for?

[phi1ipp]

@rclark

Using the SignIn Widget, how can I get the session cookie, and set it on the current server session?

Are you talking about Okta session cookie or your backend server session?

@rclark

I can see that it sets two attributes on the session, okta-oauth-nonce and okta-oauth-state , but I cannot find any documentation that tells me what those are used for?

Those can’t be used for purposes which we are discussing. They are used for OAuth authorization flow to protect from replay attacks and preserve a state of a client through the flow.

[rclark]

Hi @phi1ipp, I am talking about getting the Okta session token. I read in the documentation that I need to get the session token and use it to call the session APIs to get the session cookie.

[phi1ipp]

@rclark

I am currently using oktaSignIn.hasToeknsInUrl() and parsing the access and id tokens, and then passing those to my server for verification using the JwtVerifier

If you are doing this, then you are already have session cookie with Okta. You can easily verify that by opening another tab and trying to go to your Okta dashboard URL. Widget exchanges your session token for a session cookie for you, when you do sign-in into OIDC application.

[rclark]

Hi @phi1ipp. I tried to verify the Okta session cookie by opening a new tab and going to Okta dashboard, but it still gave me the login prompt. On the server side, I am able to see the httpRequest cookies, and I do not see an Okta session cookie there. In the browser’s Network tab, I can see the session token in the

https://dev-xxxxxx.okta.com/oauth2/default/v1/authorize? call, but I cannot seem to get or set the session cookie at all.

[andrea]

What browser are you testing this in? Does it block third party cookies at all?

[phi1ipp]

Let me check that I’m getting you right:

1. you signed into your app with Okta
2. you open the same okta url, which you uses during /authorize call, in the same browser, and it asks you for credentials?

I’d assume then something wrong/different is with the widget configuration and the way you invoke it. Is there a chance you can post that?

[rclark]

Chrome and Firefox. Shouldn’t block 3rd party cookies.
Only blocks 3rd party cookies in Incognito mode.

[rclark]

@phi1ipp
Here is the widget config:
var oktaSignIn = new OktaSignIn({
baseUrl: “”,
el: “okta-login-container”,
clientId: ‘’,
logo: ‘images/’,
authParams: {
issuer: ‘/oauth2/default’,
responseType: [‘token’, ‘id_token’],
display: ‘page’
}
});

For some reason, it is now working when I go to the Okta dev site. Definitely wasn’t before. Still not sure howto access the session cookie.

[phi1ipp]

What do you need session cookie for?

[rclark]

Good question. I thought I need the session cookie in order to SSO to the other application that we are trying to integrate with. Is that not true? Does the application just need to be in my ‘trusted origins’?

[phi1ipp]

Strictly speaking okta session cookie allows you to access Okta. So any URL you will try to access, will be available (subject to authorization decision in Okta of course)

But I see what you are trying to achieve. So you kinda have 2 application, each one hosts its own widget and you want to do SSO, after first one signed in. Well… Yeah, it’s tricky If each one of your apps would be doing redirect to Okta to perform sign-in, it’d be an easy task.

I think you can do though:

1. in app B check if user has active okta session by hitting sessions/me endpoint
2. setup your application the way when login can be initiated from Okta also (there is a setting in Okta for OIDC apps for that)
   
   
3. create a route in the app which will process this request
4. if #1 is true, then redirect your browser to “app embedded link”, which Okta will create for app B, after you let it initiate login flow

Maybe there is something else which can be done… It’s kinda late and “better to think about it tomorrow” ©

PS: there is maybe a chance to play with custom domain for Okta and you apps, as well as the storage of tokens… not 100% sure

[phi1ipp]

Well, thanks to my colleagues, they helped me to straighten the process…

In your app B you need to check if session exists first with

oktaSignIn.authClient.session.exists().then (function (exists) {
          if (exists) {
              console.log("active session"); // get your tokens w/o a prompt
          } else {
              console.log("no session");
          }
      });

[rclark]

@phi1ipp That’s fantastic. I’m hopeful the B app will be ready to test shortly. Thank you so much for the help.
Would I need to refresh the session on the server side at all with this workflow?

[phi1ipp]

I’m not fully understand what you mean by ‘refresh session on the server side’. Are you talking about your backend and it’s own session with your front-end? Or are you talking about Okta session with your browser?

Anyway it all in your hands, how you configure your session management in the application defines what has to be done in your communications with Okta. If you opt in to only get token once from Okta at the beginning and based on a successful response you establish your local backend server session, then you don’t need to go to Okta to refresh Okta’s session (though it’s possible also).

Too many questions… I suggest you implement something and then figure exact questions/issues to be addressed.