Load on REST API in the described implementation?

Question

RESTful API

Purpose
To implement an API with a single account and local profiles. Similarity of TM at Habr.
Problem
There is not enough experience to evaluate the " crutality " of the solution. There is no goal to carry out synthetic load tests, I would like to see something like " architecture norms, do not drive too fast " or " load will grow quickly, you need to redo it "
Architecture description
A - authorization API. Here we store accounts associated with social networks, email, and everything that is supposed to be.
For specifics, let's place it in
api.company.com/
P - project. It is related to the Account API . You do not need to register in the project, the account is already set up at api.company.com . Let's place the project here:
api.project.com/
C - client. Any site, mobile app (etc.) that works with the Project API .
Interaction
Implemented in the best traditions: JWT, http statuses (200, 201, etc.), https channel , get/post/delete.. and so on, for which fans of the Orthodox REST do not throw rotten stones :)
numbers in the picture match the numbering below
- Authorization:
1 - The login form is displayed to the user. The login password is sent in the request header, the request is directed to the Project API . Something like:
api.project.com/login...with Authorization header.
2 - API Project does not store account data, and makes a request to API Account, passing the same header. Waiting for an answer.
3 - The Account API checks the login-password, and if everything is in order, it generates a JWT. It is returned by the Project API .
4 - The Project API returns the token to the client. Since the request was successful (the token was returned, although it cannot be decrypted), a local profile is created in the project. It is associated with an account.
- Normal request:
Since the token is received (described above), it is possible to send requests. The picture will fit the same.
1 - The client sends a request to the Project API , attaching a token in the header.
2 - The Project API does not know how to decrypt the token. Sends a request with a token toAPI Account . In turn, the Account API can decrypt the JWT and validate it.
3 - The token has been verified, the Account API returns the ID of the user who owns the token. The Project API now understands which user to query for. Executes and..
4 - Sends a response to the client.
For those who have read to the end, I duplicate the questions:
Will the delay increase critically?
If so, what is the best way to organize a system with one account?
PS This is not SSO , the question is specifically about interaction via API.
Thanks with tears in my eyes!

Answer 1

Looks quite normal. You can, of course, access the accounts API directly by passing a unique project ID, and the accounts API itself will generate a unique token that will be understood only by the project that the end user requests, but in my opinion this makes the whole system a little more confusing.