I'm using OAuth 2.0 Client Credentials Flow with certificate-based authentication in Microsoft Entra ID to secure my backend API.

I have registered an application in Microsoft Entra ID that protects my API. Now, I need to allow external services to authenticate and obtain a JWT token to call my API.

Since I'm using certificates instead of client secrets, I'm unsure how to handle key management for external services.

Should I:

1. Generate a key pair (certificate), upload the public key to my app registration, and share the private key with external services so they can authenticate?

2. Or should each external service using my API generate its own key pair, and simply provide me with their public key, which I upload to my app registration?

In short, do I need to manage private keys for external services, or should I only handle their public keys and let them manage their own private keys?

What is the correct and secure approach in this case?

I'm using OAuth 2.0 Client Credentials Flow with certificate-based authentication in Microsoft Entra ID to secure my backend API.

I have registered an application in Microsoft Entra ID that protects my API. Now, I need to allow external services to authenticate and obtain a JWT token to call my API.

Since I'm using certificates instead of client secrets, I'm unsure how to handle key management for external services.

Should I:

1. Generate a key pair (certificate), upload the public key to my app registration, and share the private key with external services so they can authenticate?

2. Or should each external service using my API generate its own key pair, and simply provide me with their public key, which I upload to my app registration?

In short, do I need to manage private keys for external services, or should I only handle their public keys and let them manage their own private keys?

What is the correct and secure approach in this case?

• authentication
• oauth
• jwt
• certificate
• microsoft-entra-id

1 Answer 1

This type of solution is often used for B2B API access. For example a strong financial grade option is to use the RFC 8705 standard.

First, register a distinct OAuth client for each caller of the API so that you can deny access to one (e.g. if a client certificate and key are stolen) without impacting others.

The harder part is trust and certificate renewal as you indicate in your question.

TRUST OPTION 1

You trust client certificates issued by a third party authority. In each OAuth client, configure a trust store with a long lived root certificate authority, along with an expected certificate property, e.g. distinguished name.

As an example, banks that expose Open Banking APIs may only trust client certificates issued by eIDAS and use RFC 8705.

TRUST OPTION 2

Each anization gives you client certificate details like a long lived root CA and certificate properties that you configure against their OAuth client. You never come into contact with the private key.

This is good from a security viewpoint but you add extra work for the caller to provide and renew client certificates, then provide you with details. So you need buy in from the caller.

TRUST OPTION 3

In other cases you can use your own certificate authority. This is common when you need to deploy remote software at multiple locations that calls your API.

You might also use this as an alternative deployment option if you can't get some anizations to procure client certificates but need them to call your API. E.g. issue them a keypair, such as in a PKCS#12 file and also agree a renewal process.

IDENTIFYING CLIENT CERTIFICATES

In the cases above I explain a public key infrastructure (PKI) approach that copes with renewal and has built in support for revocation.

In other cases, authorization servers may require you to use a certificate pinning technique where you register a precise public key or a hash of it.

SUMMARY

External mTLS is often used as a mechanism for making trust between anizations concrete. It should include processes for onboarding, revocation and renewal so it is not just a developer concern.