Deny List in AuthHttpInterceptor

[fm-ethan]

Describe the problem you'd like to have solved

I am trying to migrate away from using @auth0/angular-jwt + other old code to auth0-angular. In angular-jwt, I am using the ability to set a deny list as such:

JwtModule.forRoot({
config: {
tokenGetter: tokenGetter,
whitelistedDomains: [ // domains to allow // ],
blacklistedRoutes: [ // domains to disallow, overriding whiteListedDomains //]
})

However, based on my understanding / reading of current documentation, there is only an option for an allowedList, but none for a corresponding deniedList.

Describe the ideal solution

Be able to specify a deniedList inside the httpInterceptor option within AuthModule.forRoot(.

Alternatives and current work-arounds

Be very explicit in your allowedList instead of wild-carding with *.

[stevehobbsdev]

Thanks for raising @fm-ethan. With this implementation, all URLs are effectively disallowed (read: do not attach an authorization header) unless they are explicitly added to the allow list.

Can I hear more about your use case where this is not sufficient?

[fm-ethan]

I would say it is a relatively niche use case. I used to be able to allow all requests to my_endpoint/* except for my_endpoint/{specific_case, case_1, case_2, ...}. The except for filtering functionality being provided by the blacklistedRoutes parameter in my earlier code snippet. This can all be worked around, however, by being explicit about what endpoints to allow in the first place.

Perhaps I am misunderstanding something from my end too.

[frederikprijck]

Hi @fm-ethan ,

Even though we understand your use-case I think this is pretty much solvable using the current API. It will only require you to set up things differently. Keep in kmind the Allow List allows for using wildcards as well.

The complexity supporting both allow and deny list would add, doesn't sound in line with the benefit here.

There is also always the possibility to roll your own interceptor to better fit your specific needs.

Closing this, but feel free to continue conversation below.

[dmitrye]

@frederikprijck Here is a scenario where the denied list is beneficial as it reduces complexity in the configuration:

Say I have an API catalog with 20 resources and 100 overall endpoints. 90% of these needs authentication. But within each resources there may be 1 or 2 end points that should not require autentication (see example below). To create an inclusion only list would involve either complex specific rules or retructuring the resources such that authentication endpoints are split apart from non-authentication endpoints.Both of these approaches now imply that the developer needs to take into account the auth0-angular library into the architecture decisions for the backend API. By providing an exclusion list list we can surgically stop the fkow before it gets into the findMatchingRoute method using simple array filter methods/approaches.

example: GET /user <-- auth required GET /user/id <-- auth required PATCH /user <-- auth required POST /user/verify-email <-- no auth POST /user/verify-username <-- no auth

This is just one resource. Imagine if this scenario existed across multiple resources. Yes, we could move the verify methods to another resource but again youre asking us to change the backend architecture for a frontend library.

Another option is to allow the AllowedList to support a custom function that dynamically creates the allowedList with more dynamic pattern matching.