Added custom callback/redirect uri to WebAuthProvider.Builder

[MichaelPersson]

Changes

There was a need to be able to set a callback/redirect uri that was not using the
same domain as the tenant.

Use-case
The app supports x tenants, via config, and you don't want add x intent
filters to the manifest.
Instead we want to have one "generic" callback/redirect uri that we can use
regardless which tenant that was used.

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. Since this library has unit testing, tests should be added for new functionality and existing tests should complete without errors.

• This change adds unit test coverage

• This change adds integration test coverage

• This change has been tested on the latest version of the platform/language or why not

Checklist

• I have read the Auth0 general contribution guidelines

• I have read the Auth0 Code of Conduct

• All existing and new tests complete without errors

[lbalmaceda]

Let me see if I get the idea right. There will be multiple different domains and client IDs in use. Like a multi-tenant application. And you want to have a single entry on the app's manifest that can handle all of them, is that correct?

[MichaelPersson]

Yes, that's the idea.
Don't know if that's a bad idea?

[lbalmaceda]

@MichaelPersson It is the first time I hear a scenario like that. I think it's fine on the side of simplifying things. However in the end, besides brevity, you wouldn't get other advantages.
Today you can declare your intent-filters explicitly (without using the manifestPlaceholders) as explained here so if needed you could create N intent-filters that match each of the different domains you want to use.

Going further and thinking now again on the intent-filter generated by this SDK for you, what would change between them is only the "host" part, right? Because the client id is not being used at all, and you could keep the same scheme on all of them. If that's the case, then I think that what you need today can be achieved without the changes in this PR.

You could declare an intent-filter that for the "host" part uses a pattern to match the different domains you have.

[MichaelPersson]

@lbalmaceda Yes, you are correct. I'm already using the custom intent-filters and that will work.

But being at a large organisation a few benefits, for us at least;

• one generic callback uri we can "enable" new tenants, read regions, without doing a new release of the app.
• for whatever reason a tenant/application is "replaced" we can handle that.
• a maintainability perspective we would also benefit from this, eg. one domain with one assetlinks file.
• Developers does not have to necessarily have access to a tenant dashboard etc.

I'm not saying this makes any sense but I have tested this and for us it works out pretty good ;)
If you are interested to hear more about our setup don't hesitate send me mail.

Note: Currently not using the logout but I guess it's the same scenario for that callback uri.

[MichaelPersson]

Alright, went through this one more time and now I got what you meant. You are right, I should be able to handle all callbacks if I play this right. Thanks!
Closing this for now ;)