Are wildcards allowed in IdentityServer Client Redirect Urls

Question

I'm running through cooking up my own test IdentityServer, but I'm hitting a snag. The ClientUri and RedirectUris must be specified for every browser based client. I know these can be stored in the DB, but is there any way to insert wildcards here?

Each of our customers receive their own subdomain and I would like to simplify user management by allowing all browsers attempting to access any of our apps at *.ourcompany.com to be treated as the same client in the identity server. Is this possible.

Planography

If you do this incorrectly you could have an attack where a.ourcompany.com could attempt to use uri's for b.outcompany.com. Be sure that you do this properly otherwise you have a disaster. – Franciscka

How could subdomains "use uri's" from another? There are only 2 main apps that would have customer specific data and security tokens for users would specify what company they are allowed to access data for and be signed to avoid tampering. – Planography

Answer 1

You can implement your own redirect URI validator. But for security reasons, this is not recommended as it expands the attack surface.

1. Redirect Uri Validator Interface
2. How to register your custom validator
3. Discussion about redirect uri

Identity Server4

I think you can add AddCustomAuthorizeRequestValidator in the startup. Still, it is not recommended to modify the redirect URI validation.

1. Add Custom services
2. Related Discussion

Adust

Yeah, at this point IdentityServer is looking too heavy for me. Plus v4 is the latest, but it doesn't seem to have the documentation I need for custom user stores and such (the links above are to v3). The biggest problem though is that I would like to implement a scheme in which the STS simply mints an identity/authZ token and returns it to the browser instead of having to define all of these roles and scopes in the STS. I don't need all the inter app functionality. – Planography

Sorry I didn't see this is for identity server 4. Modified the answer little. If you someday need same user store for different apps, investment on identity server will pay you off. Regarding documentation and samples, even though they can improve, I think there is enough to get up and running in production. – Adust

I think its the full feature set that weighs it down. My apps all have the same set of x509 certs installed on their machines so I can validate and decrypt a token anywhere. Meaning I can do a simpler ownership based auth without having to make my STS define all of these scopes and clients and resources. Trying to set up IDServ4 in my situation just made my head hurt, because I knew most of the config I was doing was unnecessary. An instant logout feature and request filtering are the only things that will require the STS to know anything about the consumer apps. – Planography

seems valid argument :-) – Adust

Is there any side effect injecting IClientStore into IRedirectUriValidator? My first implementation was inject IDatabase, but then realize I was trying to cache client config in both places. Just want to make sure it's not causing unintended consequences. Thanks. – Puerilism

Sorry, I don't know about such consequences as I haven't tried implementing a custom IRedirectUriValidator. Default implementation was good enough for all my scenarios. The consequences depend on what you want to achieve and how you implement it. – Adust

Answer 2

For IdentityServer4, you can implement your own IRedirectUriValidator and register it using the AddRedirectUriValidator extension method in Startup.cs.

services.AddIdentityServer(options =>
    {
        // ...
    })
    .AddRedirectUriValidator<CustomRedirectUriValidator>();

By default, the StrictRedirectUriValidator is registered but can be overridden by calling .AddRedirectUriValidator as shown above.

Misconstruction