I'm using Azure App Service with authentication using Google and Microsoft account.
I can access mysite/.auth/me, without an issue upon login in.
But to refresh token, /.auth/refresh is returning me following exception.
You do not have permission to view this directory or page.
Not sure what access to be granted here in Azure blade.
The error message is actually a bit misleading. It's not that you don't have permission to access the API, but rather there are probably no refresh tokens in your token store. The way to acquire refresh tokens during user login is a little different for each provider. More details here:
https://cgillum.tech/2016/03/07/app-service-token-store/
In order for this to work, the token store must contain refresh tokens for your provider. If you’re not familiar with how to do this, here are some hints:
Google: Append an "access_type=offline" query string parameter to your /.auth/login API call (if using the Mobile Apps SDK, you can add this to one of the LogicAsync overloads).
Microsoft Account: Select the wl.offline_access scope in the Azure management portal.
Azure AD: This is a little complex right now, but take a look at my next post on enabling Graph API access. Follow the setup steps and this will also enable you to get refresh tokens for Azure AD (you can omit the Read directory data and the resource=… parts if they don’t apply to you). The plan is to simplify this in the future.
Related
I am designing my first dev tool with the Azure SDK (JavaScript), and I am having a difficult time understanding how to authenticate users in production so the dev tool can access the user's Azure account. The tool is going to retrieve metrics from all of the user's Azure Functions in their tenant to display React component graphs based on those metrics over time. The app will be run locally with an npm run command.
My entry point for using Azure Identity in my app was this blog post (https://devblogs.microsoft.com/azure-sdk/authentication-and-the-azure-sdk/). I like the way the DefaultAzureCredential is working in development, using the tenant for whichever developer is running it by using the AzureCliCredential. I want a similar functionality for production, but for the browser instead of Azure Cli. In other words, if a user is already logged in to Azure Portal, it will get a credential for their tenant. How do I go about this?
One of the things I tried was opting into the Interactive Browser of the DefaultAzureCredential as described in that blog post. But even though, I could see the browser method in the src (https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/defaultAzureCredential.browser.ts), I couldn't figure how to opt into this when using the actual SDK. I couldn't find that method in the npm package in Azure Identity, and the documentation (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/defaultazurecredentialoptions?view=azure-node-latest) didn't help me either. If this is the correct option for my use case, I would like to understand how to opt into it and use it.
Another thing I tried was implementing the InteractiveBrowserCredential. As long as I pass in a redirectUri with a port not already being used by my app, it did open another tab to tell me to login to the Azure Portal if I am not already logged in. This is exactly the user experience I would want in my app. However, after logging in the credential didn't actually do anything. The credential returned actually has a client Id equal to the application Id (04b07795-8ddb-461a-bbee-02f9e1bf7b46) of Azure CLI (https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in) for some reason. This led me to look into the Interactive Browser Credential and find out that it is using the Authorization Code Flow (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/interactivebrowsercredential?view=azure-node-latest). This flow doesn't seem right for my use case, since I have to register my app. I am not trying to grant users access to my app, but access to their own Azure account. Is InteractiveBrowserCredential what I should be using?
Next, I looked into all of the different authentication flows. None of them seem quite right for my use case though. The closest one I found was the client credentials flow (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow) since I am authenticating the user to their own Azure account and not my app. However, even this one doesn't seem quite right because when I looked up how to implement that flow with Azure Identity (https://github.com/Azure/azure-sdk-for-js/blob/main/documentation/using-azure-identity.md#clientsecretcredential-and-clientcertificatecredential) I found out that I have to pass in the tenant Id. But the app won't know the user's tenant Id of the user before they log in. Which flow is right for this use case?
It seems like there is a gap in my understanding. How can I use the Azure SDK to implement an authentication flow that authenticates the user to their own Azure tenant (not authenticates them to my app) through the browser?
Thank you ShwetaMathur for answering this question in Q & A. Posting the same here to help Stack Overflow community members.
To access your application by Azure AD users, your application should also need to register in Azure AD.
Once your application is register, you can acquire the access token based on different OAuth flows which is needed to call various resources(Users in your case) or protected API based on your scenario.
Azure Identity TokenCredential provide various flows to obtain an access token based on different scenarios.
InteractiveBrowserCredential is one way to launches the system default browser to interactively authenticate a user and obtain an access token.
Using access token, you can retrieve user’s info or access any other resource in Azure tenant. The InteractiveBrowserCredential uses Authorization Code Flow to authenticate users for browser based applications and to access resources further.
Client credential flow is OAuth flow commonly used for server-to-server interactions that usually run in the background, without immediate interaction with a user and help to acquire the token and call protected web APIs.
Complete reference
I have an azure AD registered application. With delegated permissions of a user with AllSites.FullControl, I'm able to get drive/root/delta in Graph API.
Problems I'm having making the delta calls as the delegated user are:
the deltas are not consistent. Sometimes I get results back after changing the permissions of a file/folder, sometimes I don't
Despite that I'm passing in these Prefer headers deltashowsharingchanges, deltashowremovedasdeleted, deltatraversepermissiongaps, I'm not getting back #microsoft.graph.sharedChanged in the response.
The above issues are my primary questions.
Grasping at straws here, but please let me know if I would have better luck with an app-only authentication. If so, how to get it set up with my existing Azure AD registered application, without access to Powershell or Windows (e.g. if I need to use a certificate instead of client_id/client_secret, as there is conflicting information about this, and only instructions on how to get it done with Powershell). I've already started to try to test this, but have not successfully found information on how to get this working in a multi-tenant use-case, wherein I'm trying to access the Sharepoint of an outside tenant from an Azure AD registered app-only authenticated application. All existing instructions I've seen thus far are not multi-tenant and grant themselves permissions in their own Azure AD portal.
It turned out that indeed, using app-only client credentials authentication was necessary to get #microsoft.graph.sharedChanged in the response, though this is not documented anywhere. In addition, deltas are being returned consistently now. Presumably, Microsoft is doing something to try to return only deltas relevant to the delegated user, although that is not enough in my opinion to explain for the lack of deltas in some cases. Nevertheless, I'm getting the response I need using app-only client credentials.
Regarding use of certificate -- it was not necessary if accessing my own tenant where the app is registered, but if accessing a 3rd party tenant, a certificate was required instead of client_secret.
I'm currently using node.js passport library to authenticate using the OIDC Strategy with an azure registered app using a client ID and secret.
http://login.microsoftonline.com/{org id}/v2.0/.well-known/openid-configuration
I am not having any trouble getting the user profile back of the person who logged in, but I am hitting a wall when trying to get the groups. In my app, I need to authorize the user based on their active directory groups. I am getting back this piece of json:
"_claim_names\":{\"groups\":\"src1\"},\"_claim_sources\":{\"src1\":{\"endpoint\":\"https://graph.windows.net/{org guid}/users/{user guid}/getMemberObjects\"}}
I'm not sure what I need to do using this to get the groups. I tried generating a bearer token, passing that in a header, and getting the groups but it says I am unauthorized using Postman. Do I need certain permissions in the app? Also why is it using graph.windows.net when I'm trying to use graph.microsoft.com?
Is there an easier way to do this once the user has logged in?
Overage indicator claim when user is member of many groups
The claim you're getting back as part of json shared in question is an overage indicator claim.
"_claim_names\":{\"groups\":\"src1\"},\"_claim_sources\":{\"src1\":{\"endpoint\":\"https://graph.windows.net/{org guid}/users/{user guid}/getMemberObjects\"}}
It means that the user is member of many groups and instead of including information about all the groups as part of token (which would make the token too big), you will need to query that information separately.
Read more about it here: Access Tokens Reference
How to get groups information?
Your application needs to make a separate call to Microsoft Graph API to get the groups information for user.
Relevant Microsoft Graph APIs
user: getMemberObjects
user: getMemberGroups
Check member groups
Permissions Required by your application
Each of the API links above mention the required delegated or application permissions that are required as part of documentation.
You will need to update your app registration in Azure AD to require the relevant permissions (and also go through Admin consent, in case the permission required needs admin consent)
Token to call Microsoft Graph API
You mention that you've tried generating a bearer token, passing that in a header, but you got Unauthorized error.
Once you're done with the permission changes for your application, acquire a token specifically for Microsoft Graph API from your application. The bearer token used to access your application may not directly work with Microsoft Graph API.
Also make sure you go through Admin consent in case any of the permissions require Admin consent. If it's a single tenant application, "grant permissions" directly from azure portal by an administrator should work, in case of multi-tenant app you can use the Admin consent endpoint.
Code Sample: Here is a quick tutorial for calling Microsoft Graph using Node.js.. you may find other good ones as well.
Azure AD Graph API (graph.windows.net) vs Microsoft Graph API (graph.microsoft.com)
You have a valid question about the endpoint.. "Also why is it using graph.windows.net when I'm trying to use graph.microsoft.com?"
General recommendation is to use the newer Microsoft Graph API, unless the functionality/information you're looking for isn't available with Microsoft Graph and only Azure AD Graph API can help. Read more about recommendation and comparison here: Microsoft Graph or Azure AD Graph
Since information about groups is available in v1 endpoint for Microsoft Graph already (not beta), you should make use of Microsoft Graph API.
Here are a couple of related SO posts: SO Post 1 and SO Post 2
I have an application registration in Azure AD which has some Graph API delegated permissions set for it.
The application is simply a page in SharePoint that is making the Graph calls, authenticating with the ADAL.js library.
I now want to make an additional Graph call on the page to a new Graph API endpoint so I need to assign the application an additional permission. I set this permission in Azure AD and save. However, the user accessing the SharePoint page is never asked to reconsent to the new permissions, therefore the new Graph call fails with a 401 Unauthorised message.
I have tried this with a number of different endpoints and permissions, and I am sure I am setting the correct permissions in the application.
How can I have the consent dialog appear for users automatically when the application permissions change?
Admin consent is not an option.
I remember having a discussion about this with a member of Azure AD team some time back and this is what he had suggested at that time (though I never tried it so it may not work).
Essentially what he suggested is that when you get Unauthorized (401) error, you redirect the user to Azure AD login again i.e. follow OAuth authorization flow again but include prompt=consent in the sign in URI. This will present the user a consent page with latest permissions. Once the user consents to the latest permission, you can redirect the user back to your application. You may find this link helpful for understanding different values for propmpt parameter: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-openid-connect-code.
Again, I have not tried this personally so it may not work. If it doesn't, please let me know and I will remove my answer.
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.