Upgrade dependency okta-sdk-java version

[dongmei-cao]

:information_source: If you have a question, please post it on the Okta Developer Forum instead. Issues in this repository are reserved for bug reports and feature requests only.

I'm submitting a

• [x] bug report
• [ ] feature request

Background info

Describe your issue or request here (if necessary). The latest version 2.0.11 of this library does not support okta-sdk-java 13.x.x. The library depends on an unsupported okta-sdk-java 8.2.5.

Expected behavior

What should have happened? The library should support the latest okta-sdk-java and other Okta SDKs if any.

What went wrong?

Please provide log or error messages if applicable.

Steps to reproduce

If the current behavior is a bug, please provide the steps to reproduce and a minimal demo if possible.

SDK Version

okta-authn-java 2.0.11

[arvindkrishnakumar-okta]

@dongmei-cao We encourage you use the Okta IDX SDK (that is built for customers to leverage the Okta Identity Engine) instead of this legacy Authentication SDK (okta-auth-java). We do not intend to do further upgrades to okta-auth-java in an effort to move users to Okta Identity Engine.

[jadiaconu]

@arvindkrishnakumar-okta Hello,

We are trying to migrate to IDX SDK but (at least) one feature is missing:

This is the code used with the okta-auth-java library: `
// Authenticate user AuthenticationResponse response = authenticationClient.authenticate(username, password.toCharArray(), null, null);

return response.getSessionToken(); ` The problem: We don't want to have a full authentication flow (with access token, etc.) that the IDXAuthentication.authenticate() wrapper provides, we just want to have a session token and initiate a login later from a SPA OIDC flow like indicated here: https://developer.okta.com/docs/reference/api/authn/#get-started-with-authentication in the /authn POST endpoint.

Is there a way to achieve this with IDX ? If not, what would be the approach since we need to migrate to Okta > 8.2.5 ?

Thank you for your help

[jadiaconu]

@arvindkrishnakumar-okta coming back with updates: after studying IDX, unfortunately it doesn't replace at all this library. It is actually implementing the full workflows, ending with the user logged in, but this is not always what we want. In some cases you would like to stop at the "sessionToken" state and continue with another kind of flow (SPA OIDC for example). For that reason IDX requires a client_id/client_secret/scopes/redirectUri application and this library requires only the auth_server domain.

Long story short: we ended up implementing the endpoint calls ourselves (/authn, /recovery/verify, /credentials/reset_password). If this library gets updated, we'll integrate it back.

Thank you for your help,

[jefftaylor-okta]

@jadiaconu Thanks for the request! What use case are you trying to implement with this flow?

[arvindkrishnakumar-okta]

@jadiaconu In addition to @jefftaylor-okta 's question above, I'm curious on what value addition does an upgrade of okta-sdk-java from 8.2.5 to the latest will bring to your use case?

[jadiaconu]

@arvindkrishnakumar-okta actually it will bring no value, everything works perfectly. The only problem is that we are using the okta-java-sdk in the same project and we would like to upgrade it to 13.0.2 (latest version). This brings a conflict with this library which uses 8.2.5.

[jefftaylor-okta]

@jadiaconu here is another resource to look into. It performs the same operations as the authn API, but works through the OAuth endpoints.

https://developer.okta.com/docs/guides/implement-grant-type/ropassword/main/#about-the-direct-authentication-mfa-oob-grant

[jbpadilha]

This issue is still happening. In case of using Authentication by calling restTemplate for instance, as suggested, we are moving away from having this library as an option. Also, the handler is useful in case of handling different types of okta return.