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.
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.