Best practice for securing rest api for third party service access-CodePudding

Background: A SaaS product implemented as a legacy asp.net webforms app. There is an associated api providing read/write access to certain data. This Api is used internally and for access by third parties. These third parties are vendors of our customers (the resource owners). For example, vendor 123 reads order data from customer ABC. The vendor access is userless, i.e. machine-to-machine, theirs to ours.

The api is currently secured using oauth 2.0 ROPC flow (Resource Owner Password Credentials - "password" grant type) with a unique user account, client id and client secret for each vendor which we create at our customers' request. The username, password, client id, and client secret are then "somehow" communicated to the vendor which they then use to get access tokens and refresh tokens for the api.

In certain cases we will no longer be able to use this ROPC flow and it is no longer recommended anyway.

What should ROPC be replaced with? What is current best practice for this scenario?

CodePudding user response：

FLOWS

The vendors should use client credentials flow and each vendor should be given different credentials, so that you can manage access over time. The simplest form of CC uses a plain string client secret and is therefore easy to migrate to from ROPG.

Client credentials flow also has 2 commonly used high security options for strong B2B authentication, which are often used in financial grade setups:

Both of these combine PKI and JWT access tokens. Even though you may not have any need for the high security options right now, it is good to understand the patterns and future possibilities.

CLAIMS

After the flow has completed, I would aim to design a useful ClaimsPrincipal that puts the API code in control. Fields such as these feel appropriate:

clientId: t6efbu6
tenantId: ABC
vendorId: 123
scope: orders_write

You may not be able to include all of these in the physical access token, and some of the data may not be available to the token issuer, but aim to produce a useful ClaimsPrincipal anyway.

Different claims may be present for internal clients. All of this will enable the API to authorize correctly, with only simple code.