dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.5k stars 10.04k forks source link

Cannot handle error if host is not reachable for JwtBearer #11368

Open vasicvuk opened 5 years ago

vasicvuk commented 5 years ago

Describe the bug

if you have more then one authentication server (JWT or OpenID) that you trust if one of them is down we are getting error:

 IDX20803: Unable to obtain configuration from: '[PII is hidden by default. Set the 'ShowPII' flag in IdentityModelEventSource.cs to true to reveal it.]'.

We should have a way to make this check optional

To Reproduce

Steps to reproduce the behavior:

  1. Add two authentication schemas with two Authority URLs
  2. Turn off one of the authorities
  3. See error when try to navigate to endpoint supporting both authorities

Sample configuration of two JWT bearer can be found here https://stackoverflow.com/questions/49694383/use-multiple-jwt-bearer-authentication

Expected behavior

Ignore authentication service if not available. Return 401 if it is the only trusted source.

analogrelay commented 5 years ago

Can you clarify your scenario? Are these just alternate ways clients can be configured and if one isn't functional, then you want to continue to allow clients configured with the other token source to be authenticated? That doesn't seem unreasonable but it's not something we've had significant demand for. I'm putting this on the backlog for now, but I don't expect it's something we'll have the resources to look at in our upcoming releases.

vasicvuk commented 5 years ago

Scenario is next. I have two authentication servers that i trust. One is issuing tokens to general users on the single environment and the second one is admin authority (authentication server) which is trusted by multiple environments. If the admin authentication server is down i still want users to be able to access environment. Currently if i have some downtime on admin authentication server all the environments are unaccessible by users.

jayeshkv commented 3 years ago

@vasicvuk were you able to find a workaround for this specific issue ?

LukeStephen commented 3 years ago

Can you clarify your scenario? Are these just alternate ways clients can be configured and if one isn't functional, then you want to continue to allow clients configured with the other token source to be authenticated? That doesn't seem unreasonable but it's not something we've had significant demand for. I'm putting this on the backlog for now, but I don't expect it's something we'll have the resources to look at in our upcoming releases.

We're in this situation right now, one identity server authentication server went down at a 3rd party company we had integrated SSO with and then no one could log in on the Azure AD instance that was configured for all other users.