URL validation prevents custom native client callback

[dpromanko]

Describe the problem you'd like to have solved

Today, the AuthApi.authorizeUrl method does validation for URLs using okhttp's HttpUrl.parse which forces the callback to be either http or https. This prevents the callback being a custom URI scheme for native clients.

The use-case behind wanting support for this is we are moving our clients away from calling Auth0 directly (via the client SDKs) and knowing the details of Auth0 (clientIds, scopes, etc) and letting one dedicated/trusted backend own all that and call Auth0 (via this Java SDK). This means we do have scenarios where we will be calling this method and the callback will be a custom URI scheme for a native app.

Describe the ideal solution

Don't enforce that the callback have a http or https scheme.

Alternatives and current work-arounds

A workaround would be to call this method as intended with a valid hard-coded https URL and then string replace that piece of it to the native app's callback URL.

Additional information, if any

[poovamraj]

Hi @dpromanko this seems to be a valid query. I was investigating this and found that we haven't changed it to avoid unintended behaviour change - #390. I will have a pass-through of it and verify whether using URI from JDK could affect the existing flow. If not, we can take this change-up in the next release itself.

We would happy if you are able to contribute to this change through a PR and test case that verifies different URLs. We will be happy to guide you through it.

Also, this should be reflected in AuthAPI#logoutUrl as well.

[dpromanko]

@poovamraj Here is what something like that could look like if we were to use java.net.URI for the validation.

I wrote a handful of test cases to give examples of what would and would not pass validation. I'm not very familiar with rfc2396 which is referenced by java.net.URI as the syntax that defines a URI, but it seems quite broad. Obviously since URIs expand well past valid http or https URLs this would introduce a lot of values that would be considered valid. I don't necessarily have any concern here because these still must be configured as valid callback urls within Auth0 itself.

It is probably also worth noting the decision behind the use of the java.net.URI constructor instead of the static URI.create() method which can be found in their documentation here where it states The constructors, which throw URISyntaxException directly, should be used situations where a URI is being constructed from user input or from some other source that may be prone to errors.

[poovamraj]

Hey @dpromanko! This looks great and we would love to merge this PR. A few small comments we can work on during the review (very small ones). Apart from that, I can see this being in our next release! Thanks again 😄 we appreciate it so much!

[poovamraj]

@dpromanko Can you proceed to create the PR with your fork? We can implement the few small suggestions and merge it

[dpromanko]

@poovamraj PR has been opened. I'll check back later today/tomorrow for feedback. I also see that the api-diff is failing on circleci but I have no idea what that is for so please let me know if I missed something that caused that.

[poovamraj]

Hi @dpromanko, We have released a new version (1.42.0) which should support this. Do let us know if you need any more help and thanks a lot for your contribution!