I've originally used Web API 2 with Individual Accounts so that users can create a new account by supplying a username/email and password which is stored in my DB.
I'm now looking to put this API into Azure API service and have looked at the documentation about authentication but this mostly talks about external authentication. Can we use Individual Accounts with Azure API or will I need to handle this myself within the actual API?
Also, with the third party authentication all the examples use a redirected website (FaceBook, Google) to get the user to log in. I want to call this from a mobile app so does it support extenal authentication using API calls or will I have to do that myself?
Thanks
The is no problem in using the security you originally used. The documentation you are looking at describes how to do claim based authentication, authentication with azure ad and internally secure your application with service principals. When using a mobile device, you can go with claims authentication. However you should first figure out what you really want to do.
Related
We have on-prem sql server database which is connected to a legacy application. The on-prem database contains the username and password for the users. We are in process of migrating the existing solution to Cloud, and using Azure AD B2C for Authentication.
As the existing system is very big, so there is a phased transition we need to do which means keeping the both system running, allowing the users to login to the existing app as well as through Azure AD B2C in the cloud app.
I stumbled across API connectors for Azure AD B2C. I want to know if its possible to implement API connector for Sign In flow, in a way that it does the authentication against the external database store (legacy database) instead of Azure AD B2C.
From whatever I researched on google, it seems that API connector is called after authentication only. Also all the samples were related to Sign up flow. Can someone please guide me for a sample to achieve the login through external database using API connector ?
B2C supports integrating external identity providers. You can find a full list of them here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-local?pivots=b2c-custom-policy
However, you are seeking to use a custom (generic) identity provider (IDP). This scenario is supported if the custom IDP supports either the OpenID Connector (OIDC) or SAML protocols. Please check that list in the URL above to review these options.
Regarding using the API connector, you can invoke the API connector before the authentication occurs in B2C using a validation technical profile in a custom policy. However, that does not achieve the actual authentication based on OIDC. Instead, it would be considered a validation step.
An overview of when you can use API Connectors is here.
You might be able to achieve a type of workaround using a custom policy to invoke your API connector to authenticate before authenticating in B2C and returning a success flag.
However, I think a better idea is to implement password synchronization. This seems like a perfect fit for you based on what you described. Users would be able to log into both your local system and Azure B2C simultaneously until you decommission your legacy authentication mechanism.
Your main requirement is that you have use a Microsoft Graph API SDK to update the B2C account password via your application backend. The bottom line is that you just need to keep the passwords the same in both systems. This is very easy to achieve with the Graph API, especially if you are developing in C# / .NET.
You also have to figure out how the B2C accounts get provisioned in the first place. This can happen in several different ways depending on your business requirements: Graph API, user sign up flow, import operation, etc.
API connectors only work for sign-up.
There's an example here but you will have to use custom policies.
I want to develop a SaaS application on Azure and deploy to the Azure marketplace. This app will be able to obtain information about the user's network. (for instance VNET information). Ideally I would like to have a single-page application that would authenticate with the user who subscribed to the app, and then make calls on a backend API tier, which would make calls to Azure management API endpoints.
The Azure docs layout a number of scenarios of how apps could interface with AD. how-to guides
I believe what im trying to do most closely matches the "Build a web app that calls web APIs" flow, which is an example of OBO. My question is, is that really describing what im doing? Is "calls web APIs" really an example of invoking APIs on the microsoft azure platform?
So my understanding is that I would develop my own API app, that would accept requests from my client browser code, which would contain an oauth token, and then the API layer would derive another token to pass onto the Azure API layer?
Im trying to keep the architecture as simple as possible, but im afraid I may be misinterpreting the Azure docs.
OBO (On-Behalf-Of) allows you to exchange an access token that your API received for an access token to another API.
The important bit is that the access token must have been acquired in the context of the user and must contain user information.
The new access token will then also contain this user's info.
So it allows your back-end API to call Azure Management APIs on behalf of the current user.
This means your API can't do anything the current user can't do.
It is limited to the user's own access rights.
The other option for authentication is to use client credentials authentication,
where your back-end API uses only a client id + certificate/secret to authenticate.
In this case the token will not contain user information.
To enable this approach, the target organization's users would have to assign RBAC access rights to your app's service principal, so it can act by itself.
You could also build a flow in your app where you setup these RBAC accesses on behalf of the current user.
Personally, I would prefer to use delegated access (OBO) whenever possible, as it will block the user from doing things they cannot do.
Though on the other hand, service principal-based access allows the organization to control your app's access better.
I have an ASP .Net Core 2.2 Web API hosted as an Azure App Service. Then there is an Angular SPA which consumes this API, hosted on Azure Storage as a static website.
I am currently using Auth0 as our authentication and identity server. I am looking at replacing Auth0 with Azure, but I've spent a couple of days now trying to figure out what I should be doing and I am completely lost.
So, the purpose that Auth0 is currently serving, and which I would like Azure to serve instead, is to protect my Web API, as well as give it identity services so that the API knows which user is logged in. So when the front end makes a call to the API, Auth0 automatically redirects it to a login page. Here the user can log in using an existing account (including social accounts) or she can create a new account. Once logged in, Auth0 provides the front end with an access token. The front end then includes this access token in the header of every API call. The access token includes identity information which the API uses to know which user is making the call. All users are stored in Auth0. So when a new user uses the front end web app, Auth0 redirects them to the login screen, where they select "Sign Up", and create an account in Auth0. Any user can do this btw - it is a public web app which anyone can sign up and use.
So, when looking at using Azure instead of Auth0, what first confuses me is that there are various authentication services:
In the Azure portal, under my app service, under "Authentication / Authorization", there is a toggle switch labelled "App Service Authentication". If I turn this on, I can set up Authentication Providers.
In the Azure portal, there is Azure Active Directory, which I guess ties in with the above?
There is also Azure B2C.
What is the difference between Azure App Service Authentication and Azure B2C? Which one should I be using? What is the difference between points 1 and 2 above? Some examples I've seen use point 1 and some use point 2.
Sorry if this is a very vague question. I am just struggling to figure out in which direction to head. I found Auth0 quite simple, but unfortunately I cannot say the same about Azure authentication. I basically just want to figure out which Azure option would be best suited to replace Auth0 as I am using it now. Thanks
Azure B2C is the proper option to replace user authentication, however you would have to go with OWIN or another solution to actually provide application specific identity/authorization pipeline.
For public-facing site I would not go with straight up azure AD for customer logins, that’s targeted more towards enterprise customer with identities in federated, office365 or on prem Active Directory.
To be honest I’m surprised you’re planning on moving from auth0 to AAD. I’m thinking about doing the opposite.
I think the "replacement" would be using Identity Server, but there's no PaaS version for it on Azure. So you should go with Azure AD or Azure AD B2C.
If you want just to create users and groups you should use Azure AD. But if you have plans to enable 3rd party identities to access your app (such as Facebook, Google or Linkedin), then you should use Azure AD B2C. For more info, please read: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-overview
I am having an unusual hard time finding an example of how to develop a multi-user Xamarin.Forms app. Imagine you wanted to develop an app for UWP, iOS and Android that users can log into and then "do stuff".
It does not matter what - for example taking notes for later access.
Since I am using Microsoft Azure, I would love to have an example which makes use of Azure Active Directory B2C for authentication (including the usage of identity providers such as Microsoft, Facebook, Google, etc.) and Azure Mobile App Service / Azure SQL, etc.
While there are samples available that show how to use ADB2C I didn't find anything related to how you would implement a multi-user app (e.g. best strategies for the database schema, access management and how this works best with an own Restful API backend and how to include it in your client code, i.e. Model, Controller,...)
Does anyone of you happen to know an end-to-end sample for this type of Scenario?
Best regards,
Christian.
To setup authentication for B2C, I would recommend MSAL. Here are some samples:
https://github.com/Azure-Samples/active-directory-b2c-xamarin-native
There are also samples available for the WebApi.
This is a simple Xamarin Forms app showcasing how to use MSAL to authenticate users via Azure Active Directory B2C, and access an ASP.NET Web API with the resulting token.
If you want to know how to setup your database to actually store user data, I would recommend using the claims provided in the token to identify the user. The best way identify the user reliably would be to use the objectId claim. It stays the same even if the user changes their email address.
The claims can also be used to show user information in your app, e.g. display name or email. You need to add the scope profile to your authentication request to get this data.
I want to store user information to a db after a user successfully logged in via a social provider (google, facebook, etc.) without calling an extra api on the client side.
In azure mobile services this is done by creating a class that inherity from e.g. GoogleLoginProvider and then by overwriting the CreateCredentials method.
See this post: Save information immediately after Google login in Azure Mobile Services (.NET Back-end)
But how can I archive the same behaviour in Azure App Services?
Thanks
Unfortunately this is not possible with App Service authentication. The authentication happens outside of your application and there aren't currently any direct hooks into the authentication pipeline. This also means you will not be able to inject custom claims into the ClaimsIdentity.
We are aware of some of these scenarios and want to try and address them, but don't have any timelines to share at this point. I believe the separate API call into the backend will be required in order for you to implement your registration. As far as implementing role-based access control, you will likely need to store the additional user metadata elsewhere.