Resource Scopes not showing on Consent Page - identityserver4

I posed this question earlier mentioning my difficulty in reaching my resource server. It just occurred to me that my consent page does not show the "Application Access" portion. It shows only the " Personal Information" portion.
When I check the scopes table I see all the scopes available in there but some how the resource scopes are not showing on the consent page
I am inclined to believe that this is most likely the cause of my woes.
I am using the following for my development
VS 2015 update 3
IdentityServer 4 rc 2
Angular2
My resource server and authentication server are in separate projects
and I am also following this tutorial and this sample codes
How do I get the "Application Access" Portion to show up?

I believe consent pages are only for identity scopes not resource scopes. They are there to ask the user to confirm consent to weather or not the application can have access to portions of the users identity as defined by the identity scopes. Resource scopes are application level and are granted or not based on weather or not the application (client) is configured to be allowed access to that resource scope.

Related

Automatically deploy an Enterprise Application on AzureAD

I have a React Application that uses Microsoft AD to authenticate users.
As a first step, and according to Microsoft Documentation, we need to register the application with the Microsoft identity platform.
This is inline with Microsoft Identity Platform Documentation, in this diagram we can see that for ALL types of applications (SPA, Web App, etc), we always need to configure an application in AzureAD:
This process is "cumbersome", and i'm trying to remove it by having the application installed automatically.
Several third-parties do this, such as Zapier, SpecFlow, etc.
Basically, they have a process where:
User logs in on Zapier
User is redirected to Azure AD sign-in page
User is authenticated and authorized
AzureAD shows the Consent Page
User consents
Application is installed on user's AzureAD
I've been reading and searching in Microsoft's Documentation, and i cannot find a single document that shows or even mentions this type of flow.
BUT, i know that this is possible, as there are several third parties that are doing exactly this, as Zapier, for example.
Can anyone point me in the right direction, there must exist some Microsoft document that explains how this process is done!
Apologies if this should be a comment, not an answer. I do not have enough SO reputation to write comments.
Zapier is published to the Azure Active Directory application gallery (1c76d9b0-0826-4b19-8706-29572657af1e). You can do this as well:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing
If an application already exists in the gallery, it does not need to be "registered" in the user's tenant, as the registration definition is defined in the gallery.
Once an app is in the gallery, users can use it only if their tenant's administrators allow this, per the settings on this page:
Enterprise applications | User settings
https://entra.microsoft.com/#view/Microsoft_AAD_IAM/StartboardApplicationsMenuBlade/~/UserSettings
From the user's end, there are other governance controls that may impact the user's ability to use your app, but I think "register your app in the gallery" is probably what you're asking for.

Why offline scope is added automatically in Microsoft Identity Platform

I am trying to use Microsoft Graph api's using OAuth 2.0
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=<client_id>&redirect_uri=https://mytestenv&response_type=code&prompt=select_account&scope=User.Read
Even though i provided User.Read scope. OAuth consent screen lists offline permission also.
How to remove this?
Try to read this document: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#offline_access.
This permission currently appears on all consent pages, even for flows
that don't provide a refresh token (such as the implicit flow). This
setup addresses scenarios where a client can begin within the implicit
flow and then move to the code flow where a refresh token is expected.
On the Microsoft identity platform (requests made to the v2.0
endpoint), your app must explicitly request the offline_access scope,
to receive refresh tokens.
It’s not currently possible to remove the offline_access scope from the initial consent screen when using the v2 endpoint with an AAD account. There is a feedback of this issue here.

Limiting Application permission scopes to specific Site Collection(s)

I need an Access Token to make calls into a SharePoint site using Application scopes (Client Credentials).
Is there a way to limit the scope of application permissions? I am currently unable to receive Admin Concent for my application as this would allow access to every SharePoint Site in their Tenant.
If we grant the application Sites.Manage.All permission, we will be able to manage all the sites. We can not limit the application scope to specific Site Collection(s).
The application permissions are for all the site collections.

With AAD Registered Applications, what can prevent a malicious insider from adding secrets and exploiting them? Redirect URL?

My organization is taking a look at the security of registered applications within Azure Active Directory (AAD) and have concerns around the ability of individuals to add client secrets and certificates for applications that are using the "application permissions" model. I'm working to help narrow the roles of individuals within the organization to restrict this, but this investigation begged the question of what a malicious insider could do if he or she could add a client secret to this application.
I've looked through the 30 Days of Microsoft Graph blog series, which is excellent, but wanted to clarify what else can be done to prevent an insider from gaining access to the permissions this application would allow.
Does the redirect URL itself protect against this kind of scenario, provided the organization retains control of all registered URLs (meaning, for example, that https://localhost isn't registered)? Based on this post under Step 3, I assume the answer is yes but wanted to make sure this is the case.
Is it technically correct to say that without the redirect URL being secured/owned by the organization, a malicious insider who could add client secrets could exploit the permissions granted by the application?
If you are able to add a client secret to an app that already has been granted application permissions to something, then this user can use the new secret to get tokens and access those resources as the app.
Redirect URL is not used with application permissions, only delegated permissions.
This is because there are no redirects in the client credentials grant flow, which is used when acquiring a token with app permissions.
It's just an HTTP request.
So you are correct in your assumption that being able to add a new secret to an app that already has permissions can be a security issue.
There are audit logs though, and I believe adding a secret/certificate is logged.

Why do i need to create a Multi-Tenant App?

I have been doing some R&D on using the MicrosoftGraphAPI to fetch the skus subscribed by my organization.
I have created an app as described in the documentation. I did all the steps in the above link except 'Assign application to role'.
Using postman am able to get the oauth2 token by sending a post request using the link
https://login.microsoftonline.com/<mytenantid>/oauth2/token
with the client_id, client_secret, resource(https://graph.microsoft.com) and grant_type(client_credentials) parameters.
After this token is obtained I can fire a get request https://graph.microsoft.com/v1.0/subscribedSkus with the Authorization header set as Bearer {token} which will return the SKUs subscribed by my organization.
So far so good. :-)
Now the requirement is I need to fetch the subscribed SKUs by one of the client (let's say having the azure ad tenant id 'ABCDEFG') of my organization.
I can successfully do that by registering an app in the client's tenant 'ABCDEFG' with the same steps as above.
This approach is fine if my organization has say 1 or 2 clients.
However, if the client numbers are more than say 30 this approach of registering an application in each Azure AD instance is not feasible.
If the application that I registered in my organizations AAD was multi-tenant then how should it help me?
What will be the steps needed to obtain the access token for each tenant?
Can somebody assist with some detailed explanation?
Since you need application-level access, you would assign one of the Application permissions listed in the documentation for getting SKUs: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/subscribedsku_list.
Directory.Read.All, Directory.ReadWrite.All
In this case you should require the Read Directory Data (Directory.Read.All) application permission.
Then you mark your app as multi-tenanted.
Now then in order for another org to use your app, they will have to be on-boarded.
You will need some kind of page where their administrator can click a button/link to start using your app.
This should redirect the admin to:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=your-client-id&prompt=admin_consent&response_type=code+id_token&redirect_uri=url-where-to-send-user-back
Once they sign in, they will be presented with a consent screen, where they can approve the permissions that your app requires.
If and when they do that, they will be redirected back to your app (to the URL you specified) and you can use the Id token to know which Azure AD tenant registered.
During this process a service principal for your app is created in their tenant, and the required permission is granted to it.
This means you can then get an access token for their tenant from: (using the same credentials)
https://login.microsoftonline.com/their-tenant-id/oauth2/token
Remember that access tokens are specific to an Azure AD tenant, so you will have to get an access token for each tenant.
One thing I would like to point out is that you should instead try to use delegated permissions if possible.
The application permission given here gives quite large access to your app, and some admins might not use your service for that reason alone.
Delegated permissions are more complex to handle, but allow your app to act on behalf of a user instead of purely as itself.

Resources