Mocking Okta service

Questions
#1

I am currently integrating Okta into our Java-based application. For UI we utilize the SignIn widget and everything is working out nicely. We are about to go productive, so far so good.

My my local environment I plan to have a mocked backend to avoid connecting my local system with our real Okta tenant. To achieve this I provided my own endpoints mimicing the behaviour of Okta. I only mocked the bare minimum but it is kind of running. But for now I am facing two problems:

  1. When SignIn widget sends username and password to my fake backend it omits redirect uri. I do not know why but I could workaround this in an ugly way. But I would prefer to stick to the “normal” process.
  2. The idea of my fake backend is to make testing on local environment easier. So real authentication is not important which means I do not transport a real JWT through OAuth flow. When callback is triggered and in the end the redirect to to the final location is initiated I see those calls in network monitor but they are not executed by the browser. I stay on the same page with the widget complaining about some internal errors. Because the actual “authentication” in the backend is successful when I reload the page also UI realizes this. So it’s basically the redirect not executed what missing here for me, but I do not like to invent another ugly workaround.

Does somebody has experience with this approache? Can somebody help? Many thanks

#2

One thing I already discovered is that the widget will do right before POSTing username and password to /authn an OPTIONS call.
My suggestion is that the widget suggest some reflective stuff from the results of the call. As I do not support this endpoint anyway (because I do not know the essential parts and what to return) this could explain the weird behavior of the widget.

#3

Even providing a fakes OPTIONS endpoint does not the trick. The widget is even not performing the OPTIONS call. What can I do?

#4

Hello Klaus,

I’m curious - why do you want to mock our Okta’s APIs. Are you trying to get around rate limits when testing or maybe you want things to run offline without an internet connection?

#5

We do have this blog post that describes some ways to test apps that use Okta.

#6

Main purpose of this is local testing. Imagine a number of developers “doing” stuff with the SSO solution (registering new accounts, authentication) with a single Okta tenant. This will lead to out-of-synch situations very quickly.
Also automated integration tests consumers of this where I want to have full control over the entire system and do not rely on externals.

#7

For the JHipster project (https://www.jhipster.tech), we test OAuth flows using Keycloak in a Docker container. We’re using Spring Security, which makes it easy to switch to Okta by overriding a few environment variable. That might be an easier solution that writing a whole test infrastructure that mocks Okta.

#8

Ok, will give this a try. Requiring an additional Docker container at local environment is legit.
Is there more then this vague hint for Keycloak? Or is it just that easy: grab a keycloak docker container start it, done?