Using admin consent endpoint vs authorize endpoint with promt=consent

Question

I figured out that there are multiple ways, an admin can consent permissions requested by an app:

Option 1: With the authorization endpoint and a parameter "prompt=consent" like this:

https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/authorize?client_id={client-id}&prompt=consent&response_type=code+id_token&redirect_uri=https://localhost&scope=https://graph.microsoft.com/.default

Microsofts quote for this is the following:

However, there is also a dedicated admin consent endpoint you can use if you would like to proactively request that an administrator grants permission on behalf of the entire tenant. Using this endpoint is also necessary for requesting Application Permissions (which can't be requested using the authorize endpoint).

Strange is now, that if I am calling this endpoint with an admin user, I can consent to the app, even to all application permissions. This is strange to me, because I thought that the admin consent endpoint is for this.
I also get a token now that contains scopes of some of my application permissions.

Now I call this endpoint:

https://login.microsoftonline.com/{tenantId}/adminConsent?client_id={client-id}&redirect_uri=https://portal.azure.com/TokenAuthorize

This works as expected and I get also the admin consent, but no token.
Also it seems that here is no difference between endpoint v1 and endpoint v2. So the adminconsent endpoint seems to be version agnostic.

My questions are now:

1. If I only want to request admin consent without getting any access token, I will use the admin consent endpoint, right?

2. Is the admin consent endpoint independent of v1 or v2 endpoints?

3. But most important: I use the authorize endpoint only to get tokens on behalf of users. But if I access this endpoint with promt=consent parameter as an admin, why does this endpoint also returns a token with some of the application (not delegated) permissions?
   (For example I added the application permission "Application.Read.All" what was returned in the token. Another application permission "AccessReview.Read.All" was not included in the token. This does not look like a straightforward implementation to me...

Answer 1

this one is old, but here's my 2 cents anyway.

1. Right. I see this as a way for non-admin users to request their admins to allow them to use the application. You provide the link for the admin consent endpoint to the users, they give it to their admin, and after that, they can do the normal authorization flow by logging in with their Microsoft account. They will not be prompted to allow the app permissions since the admin already did that for the entire tenant (unless you use prompt=consent). The admin consent endpoint grants permission to all permissions configured for that application (both delegated and application type).

2. Don't know about this one, sorry.

3. If you request the /.default scope together with prompt=consent, the user will be asked to grant access to every permission configured on the application (both delegated and application types) for the resource that comes before /.default. Example from Microsoft's documentation: "By specifying the https://graph.microsoft.com/.default scope in its request, your application is requesting an access token that includes scopes for every Microsoft Graph permission you've selected for the app in the app registration portal." So, for this example, if the permission is not for Graph API, you would not receive it in the token. But in your case, AccessReview.Read.All is for Graph API, so the other possibility is that you're specifying the scopes you want instead of using /.default, and in that case you will only receive the ones you request. So, if you ask for Application.Read.All but not AccessReview.Read.All, than the latter will not show up in the consent prompt and will not be included in the token.

I hope it helped!