OAUTH autorization

[RVC]

Hi,

We have set a policy within Azure that ALL OAUTH request nbeeds to be approved first. After approval I should expect to view (and monitor) the app in MDCA dashboard. But waiting for 24 hours, I do not see my approval within the dashboard. Where does MDCA get it's OAUTH information from

[#2]

@RVC this information comes from graph and will only be present for apps that have been consented to. If there is a user or admin consent and approval has happened it should show up. 

The approval will not though.

I would also recommend looking at App Governance as it can also monitor not only consents but app registrations as well.

If you have an app that has consent and has approval and there is a permission assigned in AAD then I would suggest opening a case.

[#3]

Hi Keith, thanks for you reply.

Do you mean, beside the approval on the app, there must be an additional consent given on graph to pass that information to CLOUD-APP?

At the moment every OAUTH request done is quested due to the Azure setting "Consent and permissions | User consent settings" to Allow user consent for apps from verified publishers, for selected permissions (Recommended), under Enterprise Applications. A global Admin has approved the specific app.

But, while I can see the last authorization for that app within the the "Manage OAuth apps", there is no record shown in the activity log as well as the user (me in tbis case) does no shown in the users list under authorzied by.

I expected at least to find my name under the user list, and as all the other users did not use the app anymore and I know for 100% sure that I'm the person who created the new timestamp, that at least an item regards the access is shown.

So, I guess I have to open a ticket with Microasoft for that, or do I misinterpret your answer that if the app is already shown in the app-list, not new logging will be visisble?

Is for that purpose app-governacne needed? The company I'm investigating this for is in negotiation with Microsoft, but are not happy that an add-on needs to be purchases. So what will be the added value for app-governance over the default features of MDCA?

[#4]

@RVC the consent is purely for the app in this case (there isn't an extra consent needed for graph). If a user has consented, and it's been approved, I would expect the user and the app to show within the OAuth apps.

I'm not sure if the approval from AAD for the app by the admin will appear in the Defender for Cloud Apps activity logs.  There are some scenarios where this might only be available in the AAD audit logs, it depends on what is sent by the service.

If a new user just consented, it's been approved, and you do not see it show up in the app (that already existed in the console) then I would recommend opening a ticket.

App Governance in this case provides more visibility.  It will also include app registrations while OAuth will only show "consents" and there are many more anomaly detections available there in addition to extra data such as if an app is accessing sensitive info within a tenant, amount of data accessed, etc...

This can be tested out with a trial as well.

[#5]

this becomes interesting. While I still think I have to open a ticket as the experience I have is not how it should be, I have one additional question (as it may be related to where we provide the approval).

As I tried to explain, the consent is given based on AAD settings. But, is there a mechanism within MDCA that a request comes in and can be approved, without having a grey period that the user can have access (use the app, with all related risk) and during a "periodic" review the app is approved or blocked? Thus, within AAD we do not restrict, but have a setting within MDCA (a policy!?) that prevent the user usews the app for accessing the data, but first (queue the request)/triggers a workflow that a admin/security officer should first review the request before it approved. Whereby the approval could be user based, for a specific group or tenant wide.

[#6]

@RVC the approval workflow only exists in AAD today, there isn't currently a way to implement a policy like this in Defender for Cloud Apps.

If this is a type of feature, you would like to see would recommend submitting your feedback at the link below:

https://aka.ms/M365Defender/SendFeedback