Can access tokens be given to a third party app's end users for a secure read/write process flow?

Question

I have a B2B web app (and API) called XYZ. I have business customer ABC (and DEF, GHK, etc.), each of which have their own web app with their own distinct users. When a new user of ABC (or DEF, etc.) registers, they also create an entry in my web app XYZ. I'd like to provide a UI form to the end users of ABC (in their respective web apps, not mine) that lets them view or edit their own custom XYZ data.

My proposed solution is:

• User J of customer ABC requests to view (and later submit with changes) my UI form

• Customer ABC validates user J is authenticated and authorized to view the form, how ever they choose to do that

• Via server-to-server communication, customer ABC requests a single-use read token and single-use write token (with a minimum length, non-incrementing, and an expiration date) for that user

• I validate the request (using a shared secret between ABC and XYZ perhaps), and send back the two access tokens

• The form uses the read token to request the data from my XYZ server, and is marked as used

• If user J does a POST with the form, they use the write token

Everything is done over TLS. Is this a valid, secure approach (in theory)? Is there a better way (using third-party cookies perhaps)?

Answer 1

I am unsure whether the end-user posts the form directly to XYZ, or if it goes through ABC to XYZ. Assuming the former, I've thought of a method which borrows some ideas from the OpenID Connect protocol.

Suppose ABC provides the end-user with a JWT upon authenticating, which will contain the following claims:

"iss": "ABC"    # ABC issued this JWT
"sub": "user_j" # The end-user's unique ID
"aud": "XYZ"    # The intended audience of this JWT
"exp": "..."    # The expiry time
"iat": "..."    # The time the JWT was issued 
"scope": "form.read form.write" # Permissions

When the end-user requests the form from XYZ it sends the JWT. The JWT contains a signature signed by ABC, which will allows XYZ to verify it's authenticity. XYZ can also check the expiry time and the list of permissions. The same JWT can be used when submitting the form.

The advantages of this method are that it reduces one round-trip by not having to specially request tokens from XYZ, and that you don't need separate access tokens for each permission, which is important if you want to introduce more permissions in future.