Example Redirect URI Pattern Does Not Play Well with Okta AuthJS

[danaronoff]

We came across a weird problem when configuring the sample app with the following setup:

• Using the suggested pattern of com.okta.dev-12345 as the appAuthRedirectScheme
• Using the pattern of com.okta.dev-12345:/callback as the redirect URI
• Using a custom OIDC configuration so that we can redirect to a self hosted sign in widget (by specifying an authorization endpoint manually)

When attempting to authenticate via the sign in widget in this setup, we noticed we were getting 400 errors about an unregistered redirect URI even though we confirmed the redirect URI we specified in the Android app config and parsed to setup the signin widget indeed matched the preregistered Redirect URI in Okta.

Further digging on the sign in widget though showed that the internal AuthJS client is looking for an absolute URI for redirects: https://github.com/okta/okta-auth-js/blob/286fb4f11339d74d0839df396081831dc5ba0373/lib/browser/browser.ts#L169

and appends the supplied redirect URI to the window location if it does not match this regex: https://github.com/okta/okta-auth-js/blob/286fb4f11339d74d0839df396081831dc5ba0373/lib/util.ts#L74

When we changed our app's appAuthRedirectScheme from com.okta.dev-12345 to comoktadev12345 and the callback to comoktadev12345://callback we were able to move past this error.

Not sure if this is desired behavior for the Auth JS library, so thought I would share this finding here.

[JayNewstrom]

Everything you mentioned sounds like intended behavior from the native side. You should be able to use com.okta.dev-12345 as the appAuthRedirectScheme (I've got it working locally).

Can you reproduce this behavior in one of our samples? https://github.com/okta/samples-android/tree/master/browser-sign-in would be the best place to start.

[danaronoff]

@JayNewstrom Yes, that was the exact sample I used. When you say you have this working locally, are you using a self hosted sign in widget and overriding the authorization endpoint?

Here is the CustomConfiguration I used for my sample

                    CustomConfiguration config = new CustomConfiguration.Builder()
                            .tokenEndpoint("{{Normal Token Endpoint for Auth Server}}")
                           .authorizationEndpoint({{"Custom Sign In Widget"}})
                            .create();

[NikitaAvraimov-okta]

@danaronoff We did not check this scenario lately. We will discuss it with authJs maintainers and return with a follow up on your case.

[danaronoff]

@NikitaAvraimov-okta Awesome, thanks. To be clear, we have a workaround, just thought you might want to update your example.

[JayNewstrom]

Hi @danaronoff as far as I can tell, we don't have any documentation pointing to com.okta.dev-12345 as usage in the callbacks. This may have changed since you reported your issue. So I hope we just fixed it without updating you. If this still exists, let me know where it is and I'll promptly update it! Thanks!

[danaronoff]

@JayNewstrom It's been a while, but I am pretty sure my point was that any redirect URI that does not evaluate to a real URL as determined by the Auth JS library will fail in a scenario where you have a self hosted sign in widget. The documentation for the sample still has a redirect URI that is not a valid URL: https://github.com/okta/samples-android/blob/d1c6e7f82f315949672229b994b0d4f391aa3140/browser-sign-in/README.md?plain=1#L18.

Not sure why this only affects self hosted sign in widgets but my guess is there is a difference in how redirects are handled in comparison to an Okta hosted sign in widget.

[JayNewstrom]

I see. Thanks for the clarification. @jaredperreault-okta would you be willing to take a look at this next week?

[JayNewstrom]

Internal ref: OKTA-511508

[JayNewstrom]

Fixed in auth-js here: https://github.com/okta/okta-auth-js/pull/1276