Configuring authorization for Webhooks is necessary to secure and authenticate requests sent to the server.
Webhooks allow apps to receive automatic notifications from other apps when certain events happen. However, this also means that hackers can use Webhooks to send requests that can damage or disrupt the server.
Configuring authorization for Webhooks allows the server to verify that requests come from a trusted source.
There are several types of authorizations for Webhooks that provide security and protection from unwanted requests.
Basic Authentication
This is an authentication method that uses a login and password to authenticate requests. The app must send the login and password in the request header to be further checked on the server.
To activate it, go to Integrations - Webhooks 2.0 section, choose the existing webhook or create a new one, and select Basic authorization type from the list:
After that, you should enter the login and password that you use to access the service.
This way, Base64-encoded login and password requests are sent, and if these requests are correct, the service gives access to the required data.
OAuth 2.0
Oath 2.0 is a standard authorization protocol that allows users to grant access to their resources on third-party websites or applications without providing them with the credentials. OAuth uses access tokens to exchange information between web applications.
To activate it, go to Integrations - Webhooks 2.0 section, choose the existing webhook or create a new one, and select Oath 2.0 authorization type from the list:
To use this authorization type, you have to provide the following details:
Token name
Callback URL - this is the callback URL you will be redirected to after your application is authorized. Ringostat uses this to extract the authorization code.
The callback URL should match the one you use during the application registration process.
Auth URL - the endpoint for the authorization server. This is used to get the authorization code. Here, the user can enter their credentials and agree to access their data on the provider's service
Access token URL - the endpoint for the authorization server. This is used to exchange the authorization code for an access token.
Client ID - the identifier issued to the client during the application registration process
Client secret - the client secret key issued to the client during the application registration process
Scope - the scope of the access request. It is specified when requesting access to protected resources and defines the application's access level. For example, scope may indicate access only to certain types of data
Send credentials as - the service in which you are authorized in the request for obtaining an access_token may require the client_secret in the form of a basic header or parameters in the request body
Here is an example of Oauth 2.0 authorization request:
