How to properly organize access to the API?

Question

API

Hello, there is a CRM system on ASP.NET Core.
To be able to integrate it with other systems, you need to implement an API.
The API includes both write and read methods.

Two questions:

I)

At the moment, I am considering the following options for organizing access to the API:

1. API_KEY = GUID + Time Quotas
When registering an API Client, an API_KEY is issued and any
request to the API must be performed with this key, specifying the API_KEY in the corresponding header.

2. access_token = JWT (OAuth2.0 ClientCredentials Flow)
When registering a Client-API, client_id and client_secret are issued.
To work with the API, the client must first complete a request to obtain a token (access_token)
specifying grant_type = client_credentials, client_id and client_secret.
And already having an access_token, perform requests to API methods by specifying it in the Authorization header.
This is the OAuth2.0 ClientCredentials Flow .

Which option is best suited for this task?

I lean more towards a simple API_KEY. Excites safety of this approach and it would be desirable to learn best practice.

II)

It is also necessary to organize a Permission approach to access rights in the API, since different API Clients may have different permissions
for calling API methods.
Those. for each API method, get the corresponding Permission, create Roles (Roles), which collect a set of Permissions allowed for these roles.
And already these Roles are issued to each Client-API.
For example:
Role - "Data Provider" contains Permissions: (ImportProducts, ImportContacts)

Is this approach adequate to organizing API access rights?

Answer 1

Tokens only make sense in a very broad system. In the narrow you always check access and that's it