Help understanding use case with okta

[keponk]

hi, hope it's ok to ask more general questions here.

I have an existing application with front/backend that relies on okta for authentication, I didn't write this app but I have access to their sources. I'm coming from a web background where I use an existing library, point it to our okta url, point the redirect back to our application, and provide a client_id, with these 3 pieces of information the magic happens.

On my rust learning path I'm attempting to create a small cli application with the same basic features of the existing app, reusing the backend API. I'm having trouble what would be the equivalent process on rust to make authentication work.

I've tried to use the examples in the docs, but most of them require a client secret which I don't have. Also, if I understand it right, there should be a way for my CLI to not need a redirect url. In other cli's i've used that require login, not with okta though, I've seen a couple different login behaviours:

• A browser opens, I login via the browser, which displays a code and I copy paste that code back into the cli
• A browser opens, I login via the browser, a message on the browser says "you can close this window now"

I would be happy with either of those options. Is there a way to achieve this with this library? Or if not, what would be the ideal flow for a cli app with this library? which example should I focus on?

Thanks in advance

[ramosbugs]

Hey @keponk,

For CLI apps, there are a couple of options, depending on your preferences and what the OpenID Connect provider (i.e., Okta) supports.

If you want to avoid hosting a redirect URL altogether, you can use the device code flow (see Okta example), which involves the CLI app (or smart TV, etc.) polling the server until the user visits a URL hosted by the provider and performs the login.

You can also have the CLI app temporarily host a redirect URL on localhost and wait for the user to be redirected back to it, at which point you can show the "you can close this window now" message. This is what the Google example does.

In either case, whether you need a client secret depends on how the client is configured with Okta. Since CLI apps are client-side and don't involve a separate backend that's capable of storing a client secret, you probably don't want a client secret here. If Okta isn't expecting a client secret, then you can just pass None in all the places this crate accepts an optional client secret. In a few places, there are separate functions (e.g., new_public_client vs. new_confidential_client) depending on whether a client secret is being used.

Hope that helps!

[tflpd]

@keponk in case you are still facing issues, I just implemented Okta login using this library for our multi tenant solution. Here is how we suggest to our clients to set up their Okta org. As you will notice, indeed no client_secret is required.
Then, when creating the oidc client I do it this way:

let client = CoreClient::from_provider_metadata(
            provider_metadata,
            client_id,
            client_secret,
        );

and for Okta I just set the client_secret value to None. Works like a charm!