CODEWITHSUNDEEP
certificatejwtopenid-connectidentityserver3
Martin
Martin

Reputation: 71

Validating signing certificate when using OpenId Connect

I'm trying to understand whether my Owin-hosted Web Api needs to validate the certificate used to sign a JWT-token.

I've set up an identity provider using IdentityServer. On the "relying party"-side, I have an ASP.NET WebApi hosted using Owin. On the RP-side, I'm using UseOpenIdConnectAuthentication to install the OpenIdConnectAuthenticationMiddleware in the Owin pipeline.

What's working so far:

  1. Any unauthenticated user visiting my web app is redirected to the login page on IdentityServer
  2. The user logs on
  3. The user is redirected back to my web app
  4. My web app receives the JWT containing the id token and access token
  5. My web app calls the user info endpoint to retrieve the claims using the access token

What I'm missing is logic to validate the certificate which was used to sign the JWT containing the identity token.

Using Fiddler, I've been able to see that the OpenIdConnectAuthenticationMiddleware retrieves the keys from the identity server (by calling https://myidentityserver.example.com/core/.well-known/jwks HTTP/1.1)

Is the OpenIdConnectAuthenticationMiddleware performing some kind of validation of the certificate? Or should I be writing this code myself?

Upvotes: 3

Views: 4767

Answers (3)

AaA
AaA

Reputation: 3694

Is the OpenIdConnectAuthenticationMiddleware

It depends on your middle-ware. if your middle-ware is retrieving the signature keys, it probably does validate the certificate. However the url is not always same, middle-ware reads the configuration (in some cases, it is at /.well-known/openid-configuration at least for Microsoft and KeyCloak) an then extracts the location of JWK and then reads the keys, so probably you will have two connection. On the other hand your middle-ware is allowed to cache these keys for certain amount of time, which means it might not connect and read the keys for some time (best and faster scenario)

In either case you will need to make sure, at least signature of JWT and the audience (aud) value of the JWT are verified to ensure token is valid and meant for your system. Other that those, there are two date header which need to be validated.

  • nbf Not valid before
  • exp not valid after (expiry date)

Upvotes: 0

Hans Z.
Hans Z.

Reputation: 54078

The flow you describe relies on the fact that the verification certificate is pulled from a TLS protected endpoint (JWKs URL) that presents a valid SSL server certificate. This SSL server certificate guarantees that you're talking to the right OpenID Connect provider.

Upvotes: 1

Soon Khai
Soon Khai

Reputation: 672

Found some explanations here

For validating reference tokens we provide a simple endpoint called the access token validation endpoint. This endpoint is e.g. used by our access token validation middleware, which is clever enough to distinguish between self-contained (JWT) and reference tokens and does the validation either locally or using the endpoint. All of this is completely transparent to the API.

You simply specify the Authority (the base URL of IdentityServer) and the middleware will use that to pull the configuration (keys, issuer name etc) and construct the URL to the validation endpoint

Upvotes: 0

Related Questions