REST Authentication / Authorization Using Federated JWT Identifiers

I am considering developing an application that provides services using REST. These services will be available through the browser and non-browser clients. I expect there will be many installations of this software that are owned and operated by various groups. I want users from one system to access services from another. They will not use the same repository. I would like the user to authenticate to his instance, and then use the token to make requests to their instance and remote instances. This is similar to using JSON Web Tokens (JWT). Each system must be configured to trust other tokens signed with certificates.

I read that this can be done using OAuth with tokens for portable JWT devices, but this seems like more overhead than necessary. Why replace the carrier token for the access token instead of just using the carrier tokens? I am wondering if OAuth is suitable, regardless of whether the system controls access to user data, where, like many examples on the Internet, but if the user has access to data stored in the system.

The next part of the problem is determining how to create these JWT tokens, it looks like it is like WS-Trust STS. I did not see anything simple and just authenticated users and returned tokens. Can it also be potentially beneficial to support token renewal and token validation?

In the past, I was able to enable this type of feature using SOAP with WS-Security and SAML Assertions. I want to see if this can be done with REST and JWT markers. There are many posts on the Internet that advise you not to create your own security framework, so I was a little hesitant to move forward. I saw that Microsoft added handlers to take care of protecting services with JWT tokens, so it seems like they see some value in this approach.

Does anyone have any idea about how the implementation of this type of identity federation for REST services in the standards and simple method?