I am using Azure v2.0 for user authentication. The access token that I receive is used to fetch onenote content using microsoft graph api. And I do store refresh token at my end to access content on behalf of user at any time. Now user opt's out of my system I want to revoke the permissions given by user to my app.
How I can revoke the access without depending on user for that. User may not manually go and revoke the permissions. Is there any api provided for same purpose.
Is there any api provided by Azurev2.0 for the same
Sorry for the delayed response here. Unfortunately we don't have a specific revocation API. And while this is theoretically possible through existing APIs, where the oauth2Permission resource type holds the consent grant (see https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/oauth2permissiongrant_delete), your app will need to be granted a privileged permission to perform this action. Contrary to the linked topic, I don't believe that the Directory.ReadWrite.All application permissions actually allows this operation.
Please create a UserVoice request to ask for this API.
Hope this helps,
Related
I have the following requirement:
create a user on AD B2C.
using the credentials of that user, I need to get access token and refresh token to access an existing api(REST SERVICE).
Active directory here is Azure AD.
I am new in oAuth and Azure. Please suggest me the steps and configuration to achieve this. (I do not want any user interaction to get access token and refresh token).
creating a user is clear to me. but if it requires any specific type of user or any required permissions, please suggest those.
To me, it sounds like your use case can be better realized with a service principal. If you don't need a user context but, consider using an SP instead. See:
Microsoft identity platform and the OAuth 2.0 client credentials flow
If for whatever reason you want to stick to non-interactive user login, you can use the Resource Owner Password Credentials flow. But be aware that:
Microsoft recommends you do not use the ROPC flow. In most scenarios,
more secure alternatives are available and recommended. This flow
requires a very high degree of trust in the application, and carries
risks which are not present in other flows. You should only use this
flow when other more secure flows can't be used.
I have a SPA React application which use MSAL for logging users in and acquiring tokens for querying MS Graph. Currently, when the user is created he/she can have two different roles, namely:
Administrator
Viewer
As is, every user is allowed to get the same scopes from AAD - Regardless of whether they are one or the other role.
This presents a problem - Because any of the users potentially have the same permissions when calling MS Graph, i.e. they could acquire the token themselves and request graph with full scopes.
The viewer role should only be able to have the [User.Read] scope, while the administrator should be able to alter every aspect of Azure AD.
Additionally, the administrator should be able to perform actions in MS graph that isn't supported by delegated permissions, i.e. creating new users.
The following makes me think that I may need to rethink the way that users are requesting resources from MS graph - which lead me to thinking that the on-behalf-of flow would be an interesting option.
As I imagine, the flow would work as follows (from when a user logs in, and requests to create a new user in my SPA)
User logs in with MSAL in my SPA
User gets the least privileged scope, i.e. [user.Read]
User creates a new user
SPA sends a request to my Web API with the users' token as bearer
Web API validates the user token with AAD
Web API validates that the user has a role of "Administrator"
Web API gets a token with ["User.ReadWrite.All", "Directory.ReadWrite.All"] scopes
Web API calls graph with the fetched application scopes on behalf of the user
Web API returns the data to my SPA
Since I'm fairly new to this world - I'm wondering if my way of thinking makes sense. In particular, I'm curious if it's really possible to request elevated permissions ["User.ReadWrite.All", "Directory.ReadWrite.All"] on behalf of a user with only the [user.Read] scope from my Web API.
Additionally, I'm of cause open for any suggestions for alternative ways to solve the above issue.
Scopes (delegated permissions) apply to an application, not a user.
Fundamentally, no matter what scopes the user gets in their token, they cannot do anything they were not already able to do.
Microsoft Graph API checks the scopes to check the application's permissions, and then checks the user's permissions to see if they are also able to do the operation.
Thus a user can never elevate their permissions through scopes.
If you have any of your own APIs, you should also handle authorization in a similar way.
If scopes are used, also check the user's permissions.
In case of application permissions (app roles with member type application), there isn't a user so your API would only check these permissions.
This is why you need to be extra careful with authorization if your back-end uses application permissions instead of on-behalf-of flow; since they don't include the user, it could allow them to elevate their privileges through your application.
I have a problem regarding the permission granted to my app by the user showing up as a scope in my JWT.
I want to allow the user to see a list of his tenants (Office 365) on my page. For this I need a token with the https://management.azure.com/user_impersonation scope. I added the permission to the Azure API Permissions. When the user first logs in he sees this:
From this screen I assume my setup works, since the user gets asked to grant my app permission for what I need (Access Azure Service Management as you). But when I paste the JWT on the JWT Debugger I don't see the scope user_impersonation among the scopes.
I get this:
I already tried to remove the app from the test-user's applications (in their Azure Portal) to get it to ask again for consent but it's still the same. Other test users have also the same result.
What I'd need is simply to see user_impersonation among the scopes. That would allow me to call the API endpoint that returns a list of my user's tenants.
You need to acquire the access token for the https://management.azure.com resource.
Or if using v2, request it for the https://management.azure.com/user_impersonation scope.
That looks like an MS Graph API token.
An access token is always only valid for one API, so you need to ask for a token for the Azure Management API.
It works now!
So, I tried to get scopes for both https://management.azure.com/ and https://graph.microsoft.com/ in one single token. As Juunas explained, you have to get a separate token for each API. But can ask consent for both at the same time though.
My flow is this now:
I log the user in while asking him to consent to some permissions (for both API's and on first login only)
I request a token in the background for the Graph API scopes
I request a second token for the Azure Management API scopes
I need to write a backend app to read & write one company emailbox.
I have registered Active Directory Application and granted Delegated permissions (read and write to user mailbox).
Question is how to get the token needed for authenticate the graph api calls(for example ListMessages).
From the document I coundn't find any working example for backend app aquiring token and make api calls.
There are two endpoint versions:
Azure AD and Azure AD v2.0 endpoints;
And two authentication method:
1. Get access on behalf of a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_user
2. Get access without a user
https://developer.microsoft.com/en-us/graph/docs/concepts/auth_v2_service
What shoud I use ? Really confused.
Thanks all.
According to your description, I assume you want to get an access token without user login page.
Based on my test, we can get an access token that run as a background services or daemons.
It requires administrator to grant the access permission once, then user will not see login popup window anymore.
For more detail, we can refer to this official document.
Sounds like you are looking for Resource Owner Password Credentials grant flow.
However its usage is not recommended.
It does not work in these scenarios:
User has MFA
User password has expired
User is federated (MS account/Google/on-prem AD)
The only scenario that I can think of where this flow is okay is integration tests of APIs where you need to test scenarios where you call your API on behalf of a user.
Here is a better way to do what you want:
Require an application permission to access user emails and have the admin grant it. Now you can use client credentials grant flow to get a token anytime you need one.
Use delegated permissions, have the user sign in once with Authorization Code grant flow. Then exchange the code for an access token and a refresh token. Store at least the refresh token somewhere secure. Use refresh token whenever you need a new token.
The first approach is more reliable but requires broader permissions.
The second has tighter security (only users who have authorized access can have their email read), but has slightly less reliability.
Refresh tokens can be invalidated, in which case you'll need the user to login again.
My application uses Azure AD and OpenID Connect to sign-in users (see https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect).
I want to be able to list users' Azure subscriptions when they've signed-in. I cannot figure what I need to do after a user has successfully signed-in and they've been redirected back to my app, i.e. how/where I get a hold of the necessary access token or credentials, and, to be honest, which is the correct API to call with said token/credentials. Can this be done? Is an entirely different approach necessary?
Look through the code in the example for an instance of AuthenticationResult. The access token can be accessed at AuthenticationResult.AccessToken and you can decide what you want to do based off that.
One of the notification events (raised as part of the sign-in flow) receives an authorization code. With the code, I was able to acquire an access token (using AuthenticationContext.AcquireTokenByAuthorizationCode) and, with that, I was able retrieve the subscriptions using this API https://management.azure.com/subscriptions. Note: ensure your AD application delegates permissions to the Service Management API.