Obtaining a sessionToken for step-up authentication via sdk

I’m working on rewriting an existing backend Java Okta integration using the okta-auth-java lib. Our previous integration was interfacing with the HTTP API directly and we’d like to clean that up with the sdk. The application uses step-up authentication. After authenticating and verifying any required factors, I get a SUCCESS response, but it has a null sessionToken. It instead has a next link that when visited, will set an “sid” cookie and redirect back to our application.

Unfortunately, our app validates the session on all subsequent requests after successful login in a custom manner and uses a custom cookie rather than sid to do so. During initial authentication, our current backend code actually makes a GET request to the next link and parses the Set-Cookie headers to grab the session id and then sets the aforementioned custom cookie instead. To reduce the risk of the changes I’m making, if possible, I’d like to maintain the current custom cookie behavior, but would like to avoid having to parse the Set-Cookie header. Ideally, I’d like to get a sessionToken back from the API and then create the session via the Sessions API. Is this possible?

Any help or suggestions would be much appreciated.

You probably are doing something wrong. As per the documentation to the library

... a user is ONLY considered authenticated if AuthenticationResponse.getSessionToken() is not null

Thanks for your reply. I believe the null sessionToken is related to this being step-up authentication (I can see in the response I get a prop for “type”:“SESSION_STEP_UP”) and not necessarily misuse of the API. The response I’m getting looks like the expected response for their docs on step-up auth: https://developer.okta.com/docs/reference/api/authn/#response-example-for-step-up-authentication-without-okta-session-when-mfa-isn-t-required, and I know that following the “next” link in the response will finalize the login by setting the session cookies on the browser.

My question is really around 2 things:

  1. Why does Okta classify my authentication as “SESSION_STEP_UP” and is there a way to change that? (Disclaimer: I am not our Okta admin and did not set up our config, so it’s possible this is a simple configuration change)
  2. Is there a way to obtain a sessionToken using step-up auth, rather than needing to redirect the browser and have Okta set the cookies on the browser?

Well, it’s something I haven’t had a chance to mess with, but from the description it looks like your application (supposedly SAML one) has a custom login page, hence you are sent to this custom login page, from where you are initiating/handling authentication and MFA interaction with the user.

This scheme is different from a standard authentication scheme, so I think, it maybe not possible for you to achieve the desired behavior w/o changing something in your existing scheme.

Honestly, I’m not quite understand how it all works and why can’t your application just set your custom cookie based on the fact that you receive a SAML assertion from Okta (of course if my assumption about SAML integration is true)

1 Like

@phi1ipp thanks again. The app was using SAML, but was not set up to receive the SAML assertion.

I’ve created a new OIDC app in Okta and am trying to now configure my custom login to use the new app, although now running into a different issue. I can’t seem to figure out how to use the Authentication API to login using my app’s sign-on policy. If I specify an audience in the request, I get an error saying “Sign-in not allowed for app ‘{appId}’”. If I don’t specify an audience, it seems the org-wide policy is used. Is it possible to use the Authentication API to sign-in to a specific application?

Edit: I’ve opened up a separate topic here for my latter question: Using Application Sign-on Policy with MFA via API. Thanks again for your help.

Usually OIDC application has their own flow, which is initiated after you authenticated a person and got back sessionToken, which you can then use to start OIDC flow as described in https://developer.okta.com/docs/reference/api/sessions/#session-token