I have an application that uses the following scopes to access data in Microsoft Graph:
[
'openid',
'offline_access',
'email',
'profile',
'https://graph.microsoft.com/Mail.ReadWrite',
'https://graph.microsoft.com/Mail.Send',
'https://graph.microsoft.com/User.Read',
'https://graph.microsoft.com/Contacts.ReadWrite',
'https://graph.microsoft.com/Calendars.ReadWrite'
]
I am using passport-oauth in my node application for authentication.
It works perfectly fine for Office 365 emails of different companies but it doesn't work for German domains (e.g. abc#abc.onmicrosoft.de).
I already tried solutions specified in Registering an application for the Microsoft Graph API in the German National Cloud
with graph.microsoft.de as the Microsoft Graph URI and login.microsoft.de as the authorization endpoint.
Currently, the app I am using is registered on apps.dev.microsoft.com.
I get this error when I try to login with my german o365 account
TokenError: AADSTS90043: Confidential Client is not supported in Cross Cloud request.
My question is where do I register an app that works for all German O365 instances since the app needs to support multiple domain accounts.
I tried authenticating with
The authorize url that results in invalid client secret error is as follows
https://login.microsoftonline.de/common/oauth2/authorize?response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A1345%2Fauthorize&scope=openid%20offline_access%20email%20profile%20https%3A%2F%2Fgraph.microsoft.de%2FMail.ReadWrite%20https%3A%2F%2Fgraph.microsoft.de%2FMail.Send%20https%3A%2F%2Fgraph.microsoft.de%2FUser.Read%20https%3A%2F%2Fgraph.microsoft.de%2FContacts.ReadWrite%20https%3A%2F%2Fgraph.microsoft.de%2FCalendars.ReadWrite&state=key%3Dlocal-dt&client_id=7beb27dd-805c-47e5-bbb4-639a3e41a9dd
The apps.dev.microsoft.com portal is a Global registration for "Converged" app authentication (i.e. the v2 Endpoint that support both AAD and personal MSA accounts). This v2 Endpoint isn't supported by National cloud deployments at the moment.
From the documentation:
Note: The Azure AD v2.0 authorization and token endpoints are available on the global service only; they are not yet supported for use with national cloud deployments.
In order to have an application that works with both Global and National Cloud Endpoint, you need to use the v1 Endpoint. This is done via an Azure AD portal rather than apps.dev.microsoft.com.
The Authorization URI you're navigating too has the correct v1 Endpoint URL (https://login.microsoftonline.de/common/oauth2/authorize) but you're providing v2 Endpoint query parameters:
https://login.microsoftonline.de/common/oauth2/authorize
?response_type=code
&redirect_uri=http://localhost:1345/authorize
&scope=openid offline_access email profile https://graph.microsoft.de/Mail.ReadWrite https://graph.microsoft.de/Mail.Send https://graph.microsoft.de/User.Read https://graph.microsoft.de/Contacts.ReadWrite https://graph.microsoft.de/Calendars.ReadWrite
&state=key=local-dt
&client_id=7beb27dd-805c-47e5-bbb4-639a3e41a9dd
The v1 Endpoint doesn't support dynamic scopes. Instead, scopes are defined by your Application Registration via the Azure Portal.
Your URL prototype should look like this:
https://login.microsoftonline.de/common/oauth2/authorize?
client_id=7beb27dd-805c-47e5-bbb4-639a3e41a9dd
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%3A1345%2Fauthorize
&response_mode=query
&state=key=key%3Dlocal-dt
Related
The azure app service provided an URL in such format https://your-app-name.azurewebsites.net
When Expose an API in azure app registration the Application ID URI is needed. But when I use the url provided by the azure app service I got the following error:
Values of identifierUris property must use a verified domain of
the organisation or its subdomain: https://your-app-name.azurewebsites.net
the URL provided by the app service is not a verified domain? and how can I make it verified?
Application ID URI is an identifier that can be used instead of the client ID when specifying a scope defined in that app.
It has nothing to do with authentication redirect URIs, where it would need to match your app hosting.
Agree with juunas and this is just additional description. Screenshot below contained the error you met and one of the supported App ID URI pattern.
I'm afraid that the reason for exposing API is that you want to protect your web API with Azure AD. The App ID URI here is used for the authorization. Your web app also requires to configure the audience, then after you integrate Azure AD authorization into your application, the scope, the audience and other claims containing in the incoming access token will all be verified. I have a sample which is based on a web api. You can see the configuration for Azure AD authorization.
And https://your-app-name.azurewebsites.net is for authentication which used for redirect from microsoft identity platform back to your own web app. The scenario can be opening your own web page which requiring user to sign in --> redirect to microsoft sign in page --> sign in then redirect back to your web page. So we need to identify the redirect URL in Azure AD.
Scenario:
(Azure-hosted) Web App. Users should be able to sign in to my app using a Microsoft Account (i.e. #live.com, #hotmail.com, etc accounts) that has one or more Azure subscriptions. The application would then allow them to view and manage their Azure resources in specific ways through my app.
Points of confusion/frustration:
ADAL vs MSAL for authentication
Azure AD vs Azure AD B2C for the tenant hosting the application
Where do you register the tenant app? In the AD B2C under "App Registrations"? In a regular AD under "App Registrations (Preview)"? On the App Registration Portal (i.e. apps.dev.microsoft.com)?
Which of the above client ID & secret do you use in the web app (in the .config file)?
The documentation for none of these seem to cover the scenario end-to-end and most of it is completely out of sync with other developments.
I am hoping here to get some point of guidance from other developers that have actually gone through this journey themselves (rather than folks that just read the documentation). In specific, I am hoping to get answers from the Azure CXP team that monitors these questions and provides official & supported answers.
Your scenario requires access to Azure APIs, thus you have to make the logins against "regular" AAD, not B2C.
You can't make your logins against MSA accounts directly as they must be members of an AAD to have access to subscriptions.
You can use either ADAL or MSAL to handle the authentication.
Note you must use v2.0 endpoint for MSAL and the "v1" endpoint for ADAL.
See limitations of the v2 endpoint here: https://learn.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison.
You register it under Azure portal -> Azure Active Directory -> App registrations.
You can also use the preview version if you want.
You will need the application id (= client id) + a key (secret) from the app registration.
The Microsoft Graph beta API (here) allows us to POST new applications to Azure AD (v2.0).
If I post these applications to a specific tenant, using a url like this:
https://graph.microsoft.com/beta/{tenantId}/applications
and also authenticated without a user, where can I view these applications? They certainly aren't on my apps.dev.microsoft.com page (I checked), and they also aren't in the list of registered applications in the tenant on portal.azure.com
PS: I know my applications are being created because I can call GET against that url and it will return the applications in that tenant, including the ones I created through the API. Also don't question why I was doing this, I was poking around figuring some stuff out about the API.
More Details: The app that is posting these applications to the beta API is registered as an Azure AD v1.0 app in the same tenant these applications are being posted to. The POSTs use the app's authentication token.
I know that apps created in portal.azure are v1 apps, and apps created on apps.dev.microsoft are v2 apps. I am making my apps through the Microsoft Graph beta API, which makes v2 apps.
Also, for those that don't click the link to see what authentication without a user means, I am getting the bearer token for the POST request using the app's credentials, not a user's credentials.
If I post these applications to a specific tenant (which is an Azure
AD v1.0 tenant), using a url like this
Here there is no version definition for the tenant. V1.0 and V2.0 are the endpoints, not means tenant. You could know about their difference from Azure AD v2.0 endpointand v1 and v2 comparison.
If you register the app in the Azure portal, the app is v1 app; if you register the app by using App Registration Portal, the app is v2 app.
and also authenticated without a user, where can I view these
applications? They certainly aren't on my apps.dev.microsoft.com page,
and they also aren't in the list of registered applications in the
tenant on portal.azure.com
If you create the app in the App Registration Portal, the app could be seen in the apps.dev.microsoft.com page(App Registration Portal), but cannot be seen in the Azure portal.
If you create the app is v1 app, the app can be seen both in Azure portal and App Registration Portal.
This is my scenario: Client Windows Forms app authenticates with Azure AD and uses the access token to access several web api services. Until now, I was using the endpoint 1 and using the Azure portal to register both apps. It seems like there's a new way now, but I'm a little lost here.
For starters, it seems like both apps (client and server) can be registered in the same app in the new apps portal (https://apps.dev.microsoft.com). I do see a place to add platforms and I have added entries for the native and web api. But where do I go from here? For instance, in the azure portal, I must configure the client app in order for it to call the web api services. How do I that here?
Is there a complete sample for this scenario like the one we have to ADAL (https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-code-samples#native-application-to-web-api)?
Thanks,
Regards,
Luis
Please firstly refer to this document to know what's different about the v2.0 endpoint .When you build applications that integrate with Azure Active Directory, you need to decide whether the v2.0 endpoint and authentication protocols meet your needs. Please see the limitations of azure ad v2.0, such as you can use the v2.0 endpoint to build a Web API that is secured with OAuth 2.0. However, that Web API can receive tokens only from an application that has the same Application ID .
The v2.0 endpoint does not support SAML or WS-Federation; it only supports Open ID Connect and OAuth 2.0 ,To better understand the scope of protocol functionality supported in the v2.0 endpoint, read through OpenID Connect and OAuth 2.0 protocol reference.
You could refer to document how to call a web API from a .NET web app with Azure AD V2.0 (using MSAL to acquire and use access tokens), and here is the code sample on Github . The document includes how to add basic sign-in to a web app or how to properly secure a web API in azure ad v2.0 .
When I try to login for the first time with new user via active directory to graphexplorer.windowsazure.net I get following scopes:
In my apps.dev.microsoft.com I have following permissions:
Why am I getting only these two scopes in access token:
Apps registered via the Application Registration Portal use the Azure AD v2 endpoint which supports incremental consent.
This means that while your app registration determines which scopes can be requested, you still need to specify specific scopes when you make the authorize request. Also, you should avoid requesting all scopes up front, rather incrementally request scopes as needed in the context of specific operations. So start out with your authorize request as you have it, with no extra scopes but when you need to send an email on behalf of the user issue another authorize request like so:
GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345
For more info on scopes in the v2.0 endpoint check out the Scopes, permissions, and consent in the Azure Active Directory v2.0 endpoint document.
For an example of an app that incrementally requests scopes, check out this Integrate Microsoft identity and the Microsoft Graph into a web application using OpenID Connect sample.
Also note that there 2 different Graph APIs:
Azure AD Graph (endpoint: graph.windows.net, explorer: https://graphexplorer.azurewebsites.net/)
Microsoft Graph (Endpoint: graph.microsoft.com, Explorer: https://developer.microsoft.com/en-us/graph/graph-explorer)
From https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-graph-api:
We strongly recommend that you use Microsoft Graph instead of Azure AD Graph API to access Azure Active Directory resources. Our development efforts are now concentrated on Microsoft Graph and no further enhancements are planned for Azure AD Graph API. There are a very limited number of scenarios for which Azure AD Graph API might still be appropriate; for more information, see the Microsoft Graph or the Azure AD Graph blog post in the Office Dev Center.
I'm not quite sure where that screen shot is coming from, but the URL you're going to is incorrect. The correct URL for Graph Explorer is https://developer.microsoft.com/en-us/graph/graph-explorer.