Using Discovery and Katana Middleware to write an OpenID Connect Web Client

In the last post I showed how to write an OIDC web client from scratch – this requires to have knowledge of certain configuration parameters of the OIDC provider, e.g.:

the URL of the authorize endpoint (and logout endoint)
the issuer URI
the key material used to sign the identity token (as well as the signing algorithm)

To make all that information ‘discoverable’, the OIDC provider can publish metadata (see WS-Federation/SAML2p metadata). This is specified here.

OIDC discovery documents live on a well known URL relative to the base URL of the OIDC provider, e.g. https://www.myoidcprovider/.well-known/openid-configuration.

So IOW – an OIDC client library could read that information and automatically configure itself so you don’t have to provide all the configuration values. This also makes scenarios like signing key roll overs less ‘painful’.

The Microsoft OIDC middleware for Katana is such an client library – its setup boils down to providing the base URL of the provider, the client id, redirect URI, the scopes and response type.

app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions

{

Client_Id = “implicitclient”,

Authority = Constants.BaseAddress,

Redirect_Uri = “https://localhost:2671/ “,

Response_Type = “id_token”,

Scope = “openid email”,

SignInAsAuthenticationType = “Cookies”,

});

Since this integrates with the MVC/Katana security model you simply need to return a 401 to trigger the authentication handshake (manually or via an [Authorize] attribute).

The middleware will be part of Katana 3.0 (currently in beta) and you can find a sample using IdentityServer as the provider here.

9 Responses to Using Discovery and Katana Middleware to write an OpenID Connect Web Client

Fabien Ruffin says:

June 21, 2014 at 16:48

Hi Dominick,

I tried your sample MVC Owin Client and it works great… except when running it under IIS (I’m using IIS 7.5). For some reason in that case I get a 401 instead of being redirected to the login page on identity server. Any idea why?

Thanks

- Dominick Baier says:
  
  June 22, 2014 at 16:01
  
  Make sure all authentication methods are disabled in IIS – and anonymous access is enabled.
  
  - Fabien Ruffin says:
    
    June 28, 2014 at 05:17
    
    Hi Dominick,
    
    Thanks for your reply.
    
    Are you saying it works for you?
    I checked my IIS config and all authentication methods were already disabled and anonymous was enabled. I tried a few things but still couldn’t get it to work with IIS. So just to be sure it was not due to something on my machine I tried with a brand new Windows Server 2012 VM on AWS, installed IIS and tried the sample again using the default website. The exact same problem is occurring.
    
    Just to be sure IIS was not getting in the way, I tried setting the “LoginPath” for the CookieAuthenticationOptions in my Startup class and in this instance it did try to redirect me to the login page I had set there. Obviously this is not the behaviour we want for oidc, but I was just trying to see if all auth redirections would have the same issue.
    
    I must be missing something really simple here, but I can’t figure it out.
    
    Any idea?
    
    Thanks
fallafab says:

June 28, 2014 at 06:23

Ok I figured it out and it was something simple and stupid.

I downloaded the KatanaProject source code so I could debug through the OIDC middleware.
What I found out is that when using IIS, the Authorization_Enpoint option was null in the ApplyResponseChallengeAsync method of the OpenIdConnectAuthenticationHandler and it was ok when using IIS Express.

Looking further in that method, I’ve found this:
if (!Uri.IsWellFormedUriString(redirect, UriKind.Absolute))
{
_logger.WriteError(string.Format(CultureInfo.InvariantCulture, “The OpenIdConnectRequest sign-in redirect uri is not well formed: ‘{0}'”, redirect));
return;
}

Thanks Microsoft! Next time throw an exception please instead of passing the request on to the next module!

The reason why the Authorization_Enpoint was null was that the OIDC middleware couldn’t reach the discovery endpoint (.well-known/openid-configuration) and populate all the required endpoint urls.
It turns out at work we’re using a proxy. For experimenting with Identity Server v3 I’ve set up some exceptions in my local proxy exclusion list to run IDSV3 on local. Apparently IIS and IIS Express have different configurations for using the default system proxy…

Mystery solved!

Thanks

Anup Marwadi says:

August 21, 2014 at 21:05

Hello, This is a great article!

I had a question related to Multi-Tenant Scenarios. We have many customers that have their own OIDC setups. Can we add multiple UseOpenIdConnectAuthentication options in the same Web API? I am trying to figure out how I would reference a specific Client’s metadata at runtime. In this setup, the application is bootstrapped with OIDC Client_id and Metadata URL thus making it work only for one OIDC provider.

Is that interpretation correct? And if so, is there a workaround? Thank you!

- Dominick Baier says:
  
  August 27, 2014 at 18:55
  
  Well – in that case you’d need to handle that dynamically. The OIDC MW has some hooks that you can implement.
  
  - Matt Cowen (@matt_cowen) says:
    
    October 6, 2014 at 20:30
    
    Hi Dominick,
    Could you point me in the right direction as to what hooks there are to use? I’ve tried changing the issuer and authority details during the redirect notification but that didn’t work. I’m currently looking through Microsoft.Owin.Security.OpenIdConnect but haven’t found anything yet that would do the job of changing the auth options in good time before the request is made. How far does one have to go?
    
    Thanks
    Matt
devdigital says:

August 28, 2014 at 12:39

Link is dead, should be https://github.com/thinktecture/Thinktecture.IdentityServer.v3.Samples/tree/master/source/Clients/MVC%20OWIN%20Client

artem says:

June 24, 2015 at 15:33

How I can send custom additional parameters?