Authorization

In order for a user or application to gain access to Treddy’s data and features, they must first be authorized and granted the necessary permissions through the OAuth 2.0 authorization framework.

To enable OAuth 2.0 in your App, you must first bee approved as an integration partner and have gained access to the Developer portal.

OAuth 2.0

OAuth 2.0 is an industry-standard authorization protocol that allows for greater control over an application’s scope, and authorization flows across multiple devices. OAuth 2.0 allows you to pick specific fine-grained scopes which give you specific permissions on behalf of a user.

Resource access is determined by one or several scopes. Scopes enable your application to access specific functionality (e.g. create a deal, update status, or to initialize a signature). The set of scopes you set during the authorization, determines the access permissions that the user is asked to grant.

The authorization process requires valid client credentials sent in basic auth header: a client ID and a client secret. You can follow the Developer portal guide to learn how to generate them.

Once the authorization is granted, the authorization server issues an access token, which is used to make API calls on behalf the user or application.

The OAuth2 standard defines four grant types to request and get an access token. Treddy implements the following flows:

• Client credentials

Which OAuth flow should I use?

Choosing one flow over the rest depends on the application you are building:

• If you are developing a long-running application (e.g. web app running on the server) in which the user grants permission only once, and the client secret can be safely stored, then the authorization code flow is the recommended choice.

• In scenarios where storing the client secret is not safe (e.g. desktop, mobile apps or JavaScript web apps running in the browser), you can use the authorization code with PKCE, as it provides protection against attacks where the authorization code may be intercepted.

• For some applications running on the backend, such as CLIs or daemons, the system authenticates and authorizes the app rather than a user. For these scenarios, Client credentials is the typical choice. This flow does not include user authorization, so only endpoints that do not request user information (e.g. user profile data) can be accessed.

• The implicit grant has some important downsides: it returns the token in the URL instead of a trusted channel, and does not support refresh token. Thus, we don’t recommend using this flow.

The following table summarizes the behavior of the different flows:

Whats next?

• Before continuing, make sure your application has been approved and that you have access to the Developer portal.

• Determine which kind of application you are going to develop and read the corresponding flow as described above.