What architecture of interaction between mobile applications and the web version with the API should be chosen?

Question

API

Good day to all. A question arose regarding the architecture of the interaction of mobile applications and the web version with the API. Suggest the best solution. Essence:
There is a backend application with API. Various mobile applications can communicate with this interface, records of which are stored in a database on the server. Each such application has its own token, with the help of which the API knows who is accessing (and, accordingly, can determine rights, etc.). It is required for all endpoints . The data is general, there is no binding to applications, and, accordingly, any application can edit any entities (which one specifically edited is indicated). To edit data in all cases, the user must log in (that is, in addition to the application token, anotheraccess token ).
In addition to mobile applications, users should be able to log in to the web version (Angular.js) and from there, from the admin panel, also have access to data editing functionality.
Question : how would you organize the process of interaction between the Angular web admin and the API with the existing concept of communicating external sources with the server?
Current variant : there is an application with a token in the database, from which the angular.js application is running. Is this approach normal or should the interaction of your own frontend with the backend be organized somehow differently? Thank you!
---

1. I wouldn't use Angular in this case at all.
One jquery would be enough.
2. We write an API interaction class, methods (authorization, where to get it from (URL) and where to put it (DOM-node), etc.)
3. We write a manipulator class using the API work class: take-put, replace send etc.
4. Use the methods of the manipulator class to handle object events (clicks on links, etc.)

How frontend with API will work is clear. Angular or jQuery is not the point. The essence of the question is in the interaction architecture: is it necessary to allocate a separate application for the web or, for example, determine in the API that requests come from the server IP, which means they are from our admin panel, etc.

The application will be dismantled, the token will be obtained, and anyone with this token will access the api.

The token is only for identifying applications ("what is it?"), security is provided by user authorization.

Answer 1

1. I wouldn't use Angular in this case at all.
One jquery would be enough.
2. We write an API interaction class, methods (authorization, where to get it from (URL) and where to put it (DOM-node), etc.)
3. We write a manipulator class using the API work class: take-put, replace send etc.
4. Use the methods of the manipulator class to handle object events (clicks on links, etc.)

Answer 2

Current variant: there is an application with a token in the database, from which the angular.js application is running. Is this approach normal or should the interaction of your own frontend with the backend be organized somehow differently?
It is pointless to store the token in applications running on the client. The application will be dismantled, the token will be obtained, and anyone with this token will access the api.
As a rule, official applications do not restrict rights. Restrict applications from third-party developers and this is done through the OAuth 2.0 protocol. What rights to give a third-party application, the user decides. The token is issued to the user. It makes sense to issue a token for the application itself only if the application is running on the server side, otherwise it is pointless. More details in rfc6749
I don't understand why you need to issue a token for an application. Restrict endpoints set per application? What for? What does it give? Describe the task.