Add Webhook Authentication Methods

JSON Web Token (JWT)

This method consists of three parts: a header, a payload, and a signature. The header contains information about the type of token and the algorithm used for the signature. The payload contains the claims or information about the user or entity being authenticated. The signature is created by hashing the header and payload with a secret key to ensure the integrity of the token.

OAuth 2.0

OAuth 2.0 provides multiple layers of security, requiring Bringg to access a token to include in your webhooks. To use OAuth 2.0, create an app in the receiving system to generate a Client ID and a Client secret for Bringg to use when requesting an authentication token.

You can determine if OAuth 2.0 data is included in webhooks as a form, JSON, or query strings.

Static Headers

Include an authorization token or API key in the header of the HTTP request.

Client ID

This is the public identifier for your OAuth app and does not change, even when you regenerate the key. You can think of this as the app username.

Client secret

This is the key that Bringg uses to request an authentication token. You can think of this as the app password.

Authorization URL

This is where Bringg sends the token request, including your Client ID and Client secret key.

Path

(Optional) A URL path includes a forward slash / and content following it. For example, in the URL for this article, the path is /docs/webhook-authentication-methods-copy.

Request type

This determines how Bringg includes your OAuth data in webhooks:

- Form: included as form data in the body of the webhook HTTP request. The header Content-Type: application/x-www-form-urlencoded) instructs your listening system to parse the included form.

- JSON: included in the body of the HTTP request using JSON formatting.

- Query strings (qs): included in the HTTP request URL. This is generally considered less secure than the other options.

Scope

(Optional) Scopes determine which data in the receiving system Bringg's webhooks can change. The structure of scopes varies and depends on the structure of your listening system, but they are typically formatted as access level: resource. For example, read:orders.

Select None to send an empty set of scopes, or select Enter your own to add the required scopes for this webhook.

Resource

(Optional) This is the resource that the authentication method is requesting access to.

Headers

(Optional) Add static headers to be included in all webhooks using this authentication method. Static heads are made up of key-value pairs.

Signature key

This is the key provided by your receiving system and appears below the webhook payload as part of the signature object.

Token expiration

This indicates how long the token can be used before it expires, in minutes.

Issuer (iss)

This is the identity of the entity sending the webhook (Bringg).

Algorithm

This is the algorithm used to encrypt the signature key.

Audience (aud)

This specifies the audience for your webhook. This is one way that your systems filter the payloads they receive.

Subject (sub)

This is a unique identifier that is recognized by the recipient system. This could be an email or a tag like bringg-event.

Encoding

(Optional) When base64 encoding is enabled, the header and payload are converted into ASCII string format, making it possible to send where text-based communication is required or preferred.

Not before (nbf)

(Optional) This determines when the token becomes valid. It cannot be used "before" the specified time. This should be formatted in Unix epoch time.

Token Type

This lets your listening system know the structure and format of the access token.