I'm developing a REST application and I allow my clients to authenticate in several ways (typically using Authorization: Token ... as in OAuth 2.0, but also there's session-based auth option for the web-browsable API). The application allows the client to provide their endpoint to which my application would later POST with some data whenever a particular event happens.

Now I wonder: what's the best way for the client application to authorise that it's my application calling?

Should I roll something up myself (like, include a token derived from the client application secret, which the client app would then verify), or is there a more conventional approach I can follow?

  • This is addressed in the Oauth 2 RFC. I don't know all the details, but the gist is to use TLS (basically https) and the client can check your certificate to be sure it's you.
    – Michael K
    Mar 4, 2014 at 0:14
  • @MichaelK Not sure we're on the same page; this interaction seems to live outside of the scope of OAuth. Assume a client has set up a callback inside my application that asks me to post to https://client_app.example.com/callback_for_myapp. When my app is about to POST there later on, are you suggesting that the client should rely on TLS Client Authentication and call it a day?
    – Kos
    Mar 4, 2014 at 15:52
  • 2
    Yes. Of course you can create a token-based system if you wanted, but since you need to use https anyway (else your tokens wouldn't be secure) why not use what's already provided? Also, Ouath2 is a flow designed to allow users to authorize clients to have access to their resources on another server. It's not really intended to authenticate the client to the server or vice versa.
    – Michael K
    Mar 4, 2014 at 21:51

2 Answers 2


The API is yours, so it is up to your clients to adapt to it, not the other way around.

If some of your clients require authentication on their https://client.app.com/callback-for-youapp I think they'd have to figure that by themselves. For example they could include a token when calling you so that when you call them back they can authenticate your call ex :

Your client subscribing: POST https://your.app.com/subscriptions { "...": "..." "callback": "https://client.app.com/callback-for-youapp?token=xyz" } So when your are calling back on https://client.app.com/callback-for-youapp?token=xyz They can authenticate your request using the token in the query string.

  • I think it's best to avoid putting sensitive information in URLs. URLs tend to get logged in services ("Calling back https://... ", "Call to https://... succeeded"). Even if your app doesn't log the URL, your http client library or outbound proxy might. Request headers / POST message bodies will be a lot less exposed. Mar 29, 2022 at 17:51

If your clients are other teams in your company, producing services in the same cloud platform account such as AWS or Google Cloud, then you can probably use your cloud provider's built in IAM solution as usual. Example: https://cloud.google.com/workflows/docs/creating-callback-endpoints#call-endpoint

Otherwise (e.g. if your clients are on the public internet), you could require your clients implement any kind of authentication that a server would normally use.

  • For example, you could make your clients register an OAuth endpoint and client ID / client secret with you, and then you authenticate to them using that information which they provided you. Instacart Connect does this: https://docs.instacart.com/connect/api/authentication_webhooks/

  • Or, you could make them give you an api key, and then send that api key on each callback.

  • Or, you could use client certificate authentication. Since your service is the client in the case of a callback, you can provide your public certificate to them during integration, and expect them to check that each callback is valid against the certificate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.