Can anyone suggest the Azure AD sign-in/ Sign-Out code flow for the Asp.net core Web API.
I am developing the Web API project(same as https://app.hubspot.com/crm-settings-email/6849578/email/connectedEmails) for Office 365 integration and have implemented all the required MS GRAPH API but stuck with the Sign-In/Sign-out process for the Personal Microsoft account holder. tried the sample code for OpenId-Connect V2 code flow but not able to return any Access Token or Code in return.
Can anyone suggest the correct code-flow for Web-API project and the how to register or sign-in/out the any Microsoft User into my Azure APP?
I believe Authorization code flow is good for your requirement as you have mentioned .net core Web-API project. Please go through Ms document for different implementations of other authentication flows (which can be implemented MSAL library) which helps you to choose your own code flow based on your scenario.
Please go through sample given by Microsoft which helps you in handling AAD login with personal accounts. Also, Please make sure you have selected Accounts in any organizational directory and personal Microsoft accounts option while creating an app in app registration.
Related
Please help me.
To login into Azure active directory how to use MSAL.Net library in my login page of my website.I am seeing very big samples online but I didnt find small peace of code which makes me to understand MSAL.
MSAL Library is just an implementation for enabling developers to acquire tokens from the Microsoft identity platform endpoint.
If you want to use MSAL to acquire a token, you need to:
Register an application in Azure AD.
Add target API, and grant consent to select permissions.
Generate a secret key.
Then you can get a token as Acquire a token and call Microsoft Graph API.
However, I think what you really want is to integrate AAD. You can easily enable AAD authentication for your .NET web application. It uses OWIN middleware.
If you are using a aspnet or aspnetcore, you can get the necessary code needed to sign in your web application with your Azure AD tenant just by following steps.
Create the sample from the command line
Note that MSAL.NET is a token acquisition library (for services like MS Graph and such) that can optionally sign-in users as well. the sign-in code is present in the aspnet and aspnet core SDKs
We are building a Xamarin Native mobile apps and using Azure AD B2C for authenticating users using their social logins.
We decided use MSAL native library (Xamarin) for authenticating using B2C. And our mobile app required to manage(full access) the signed-in user profile. Since this feature isn't available in MSAL we have decided to go with ADAL for the time being. Followed the instruction provided in the link below and the sample works. But I started experimenting by deleting the API access provided in the application (created in b2c tenant) and the ran the application with "Get-user" parameter. And the application is still able to get the users from AD. Not sure how secure is this thing?
Then deleted the application key from the B2c tenant application and ran the console application sample. And received an error AADSTS70002: Error validating credentials. AADSTS50012: Invalid client secret is provided.
Trace ID: cef09957-06bf-462e-a0c3-4ed6bae11e00
Correlation ID: afab126d-8694-479a-8a21-c12eb7cb176c
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
Any Idea why this is happening. I would like to implement this on a xamarin.ios app and any guidance much appreciated.
The answer to this is very similar to the answer to your other question: Exception access Azure AD B2C using ADAL library for user management, which can be summarized as:
Azure AD B2C does not yet support delegated permissions to the Azure AD or Microsoft Graph. The correct way to work around this limitation at this time is to have your native client application call a web API (using MSAL) which would in turn call the Graph API (using ADAL). This web API is an API you build which has authorization logic to scope the user management operations.
Once user management in Azure AD B2C is supported via the Microsoft Graph, you won't need this API and will be able to use delegated permissions (vs application permissions using client credentials) to have your native client application talk directly to the Microsoft Graph. In the interim, you'll have to stand up your own Web API as per the guidance above.
UPDATE: the Azure AD v2.0 endpoint and Microsoft Graph API now support client credentials flow, so you can also use MSAL for your Microsoft Graph API calls. However if you need to call the Azure AD Graph, then you will still need to use ADAL.
I'm new to the Microsoft Graph API and Azure. I'd like to seek advises to which Microsoft Graph API version I should go with and whether I should be using the "Web API on-behalf-of flow" for my scenario.
I'm building a web services which can store access tokens of multiple Office 365 users from different organisations. This web services can then create web hooks via the Microsoft Graph API to get notifications about calendar appointment changes in these users' accounts, in order to sync these changes to the corresponding appointments stored on our own server.
So it's a mass Office 365 calendar syncing web service in a nut shell.
I have gone through a lot of their GitHub sample projects and managed to create web hooks with the v1 graph subscription API and was able to interact with the calendar of my dev account, all in a sample APS.NET MVC project.
But I'm very confused about the following parts:
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
Microsoft Graph and Azure AD developers could you please shed some light on this part for me? Microsoft isn't doing the best job when it comes to documenting these parts.
Because this web service does not directly provide a UI, so the login UI would be presented by a separate desktop (WPF) client, and I believe when this is done on the client side, I can forward the authenticated access token to my web service to create the web hooks? This sounds like the "Web API on-behalf-of flow" scenario Microsoft described here: https://learn.microsoft.com/en-au/azure/active-directory/develop/active-directory-v2-limitations.
Yes, the scenario is on-behalf-of flow and this flow is not supported for the v2.0 endpoint at present.
Because this web service needs to create web hooks to multiple Office 365 accounts from different organisations. I'm not sure if this counts as the a multi-tenant scenario. If this is the case, it looks like I can only use the v1 API because the v2 API only allows the web service to receive tokens from an application that has the same application ID (also described in the page linked above).
You can only use Azure AD V1 endpoint, because the V2.0 endpoint doesn't support on-behalf-of flow. And here are some steps for using V1 endpoint for your reference:
register 2 apps, one for the WPF(native app) and one for your web service(web app)
enable the multi-tenant for the app for web service
grant the relative Microsoft Graph permission to the web app
set the knownClientApplications for the web app using the clientId of the native app
grant the relative Microsoft Graph permission and web app to the native app
After that, when the users login-in in WPF first time in different tenant, the users can conesent the two apps at same time. And then the service principals of two apps will be register to users' tenant. After that the web service can use the on-behalf-of flow to get the access_token for Microsoft Graph based on the token from native app.
More detail about multi-tenant developing, please refer below:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
And the code sample below also be helpful:
Calling a downstream web API from a web API using Azure AD
I'd like to add an Office365/Graph Calendar integration to an existing Node.js app (hosted on AWS). I've already done a similar integration with Google's Calendar, and it was trivial to get set up. I'm not having nearly as much luck with the Microsoft version of things.
I've found at least 4 different ways to register an app (get a clientId and clientSecret), and I seem to get different errors for each of them, but can't get any to work properly.
I think a large part of my problem is that I've never had to work in the MS ecosystem before, so I don't have a lot of the baseline knowledge that the documentation assumes.
I'm not looking to host anything with Microsoft - do I even need an Azure account?
I'd like to allow any user with an Office365 account to connect it to my app - do I need to learn about Active Directory to do this? Does this part of it require Azure?
I've found instructions for using both https://login.microsoftonline.com/common/oauth2 and https://login.microsoftonline.com/common/oauth2/v2.0 for this, do I need to worry about which version I use depending on how I registered my app?
Microsoft Graph leverage Azure AD to authenticate and authorize users. The doc refers as:
To get your app authorized, you must get the user authenticated first. You do this by redirecting the user to the Azure Active Directory (Azure AD) authorization endpoint, along with your app information, to sign in to their Office 365 account. Once the user is signed in, and consents to the permissions requested by your app (if the user has not done so already), your app will receive an authorization code required to acquire an OAuth access token.
So you need to register an Azure account for configure the Azure AD service. Refer https://graph.microsoft.io/en-us/docs/authorization/app_authorization for more info.
Meanwhile, to implement Microsoft Graph in node.js application, you can refer the following code sample for your information.
Microsoft Graph service app sample using Node.js
An Office 365 API sample app using Node, Express and Ejs
Office 365 Node.js Connect sample using Microsoft Graph
Matt, you can do this without an Azure account if you use the oauth2/v2.0 auth endpoint. When you do that, you can register on apps.dev.microsoft.com using a Microsoft account.
See this tutorial for doing it with the Outlook REST API, which is similar to the Graph (in fact, for Calendar operations the calls and entities are identical).
I'm creating a Node app that uses OAuth2 to login a user and use the Office365 API to send and receive email, and possibly contacts and calendar events.
I have no need for Azure Active Directory that I know of. However, I am unsure of whether or not I need to register the app with Azure for the OAuth flow.
At first I followed this tutorial, which involves registering the app in the "Application Registration Portal." The OAuth token I receive currently works with the REST API for Outlook. No Azure.
Then I saw this tutorial, which seems to suggest that any app using the Office365 APIs should register an app with Azure. I don't want to do this if I don't have to, mainly because of the cost.
It is not clear to me why I need to sign up for one or the other, and my main concern is that the first tutorial is dated to the point that my app's registration with the "Application Registration Portal" will become deprecated and I will need to switch over to registration with Azure at some point. I have seen plenty of outdated tutorials and information from MS that are not clearly marked as deprecated. Can anyone help clear this up?
Sorry for the confusion. The short answer is that both these methods are still relevant, so none of them are deprecated yet.
Firstly, you're right that you need to register your app to call the Office 365 APIs.
And, you're also right that there are currently two different places to register an app: the App Registration Portal and the Active Directory section under the Azure Management Portal.
Registering on either one of these is enough to get you to a comfortable state where you can call the Office 365 APIs.
However, the convergence of the Outlook.com stack with the Exchange stack means that you are now also able to use the Office 365 Mail, Calendar and Contacts API against consumer Outlook.com accounts in addition to Office 365 accounts. If you wish to take advantage of this, you should register your app in the Application Registration Portal and NOT the Azure Management Portal.
Another advantage of registering through the Application Registration Portal is the support of dynamic permissions scopes. You don't have to specify upfront when you register your app what permissions it requires; rather, you can request permissions at runtime using the scopes parameter.
This new v2 app model for apps registered in the Application Registration Portal is currently in preview. A reason not to register apps in the Application Registration Portal is if they will be using more than just the Mail, Calendar and Contacts APIs. e.g. if your app is also using the OneDrive for Business Files API, you wouldn't be able to request tokens using the v2 app model's endpoint. In that case, you should register your app in the Active Directory section under the Azure Management Portal.