If you want to avoid manually consenting to applications in Azure AD using the "Grant admin consent" button in the API Permissions blade then read on. There is now a permission you can give an application to allow it to grant consent, DelegatedPermissionGrant.ReadWrite.All.
If you want to assign users to an application there is now a permission for that too, AppRoleAssignment.ReadWrite.All.
You need to use Microsoft Graph Beta to make the calls for granting consent. You can see an end to end example called admin-consent at www.github.com/mattcowen/postman. Here is an example request...
POST /beta/oAuth2Permissiongrants HTTP/1.1
Authorization: Bearer eyJ0eX....
The client id is the the object id of the service principal for the application I want to consent users for. I want to allow this service principal to communicate with a custom API I've registered in my AAD. The resource id is the object id for the service principal of my API. That API exposes a permission or scope called Api1-User-Access. So here I am granting consent for all users in my AAD to access my API from my new app (AllPrincipals with a null principalId is effectively all users).
N.B. For users to be able to access my new application, I would need to also consent to User.Read. The example above is only consenting to accessing the API.
Also worth noting that AppRoleAssignment.ReadWrite.All gives permission to manage permission grants for APIs as well as the DelegatedPermissionGrant.ReadWrite.All permission.
If I create an application in AAD then by default, all users in the AAD tenant would have access to it. To enforce only certain users or groups have access without having to write code, I can enable "User Assignment Required" under the service principal for the application (in Enterprise Applications > Properties). Here is an example request.
POST /beta/users/7b4874ff-90d3-4b03-b316-5962e6ccf3a2/appRoleAssignments HTTP/1.1
Authorization: Bearer eyJ0e....
I make a call to /appRoleAssignments - the guid highlighted in the URL and the principal Id for the body is the object id of a user in my AAD that I want to assign to the app. It could be a group or another service principal.
The app role id represents the id of the role added to my new application manifest. I created this when creating the application as can be seen in the postman example. The resource id is the new application's service principal object id.
It is worth noting that I was able to assign a user AND grant consent to my API using just AppRoleAssignment.ReadWrite.All permission.
An end-to-end demo using postman is available here. This will create an application, assign a user and grant consent for all users in the AAD tenant.