Scenario 1
An existing monolithic .net core MVC application with an existing Account Management workflow for sign-in/up. The application makes use of Microsoft.AspNetCore.Http's IHttpContextAccessor to handle the user in the http session.
Scenario 2
An existing application with a NextJs front end and a .Net core Backend. The login is server side and uses a JwtBearer Authentication scheme.
Requirement
Add authentication via third parties Identity Providers, like Google, Microsoft, Facebook, ecc. The addition of the Identity Providers should have the minimum impact on the previously existing workflow.
Main area of confusion
Performing some tests with Azure AD B2C, I noticed registering the User Flow for Sign up and Sign and clicking on Testing the Workflow that the generated page always asks for email and password. I wonder if it is possible to use it only for the external providers without using the email and password flow from AD.
Question
Does Azure AD B2C fits the need for Scenario 1 and Scenario 2? If so how should it be configured?
Related
I have a front end SPA (single page application) and back end api.
Each event in the SPA (like button click) invokes the respective api endpoint, and displays the result in the SPA.
I want to implement Azure AD based authentication so that only my Azure Tenant users are able to use the SPA/api.
Is the following flow correct approach to implementing such a feature:
User opens the SPA
User clicks on login button which opens Microsoft login popup
User enters Microsoft credentials in the popup, and if credentials are correct then user gets the JWT token
For every subsequent api request, the JWT token is placed in the bearer header
The endpoint validates the JWT token using Azure public key and rejects the request if token is missing or validation fails.
Is this flow correct and what is such a flow called?
There are several implementation steps that needs to be performed before you will have the flow that you have described:
User flow needs to be configured (Azure AD) - e.g. selfsignup allowed?
Backend and frontend applications needs to be registered (Azure AD)
Permissions and scopes needs to be added (Azure AD)
Backend API needs to be configured (e.g. API management) in order to validate the JWT token
I highly recommend to configure one of the Azure sample implementations end2end to get and idea of all the needed tasks: https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-authentication-sample-spa-app
The steps you outlined are correct.
An OAuth 2.0 "flow" outlines the steps to acquire a token from an Identity Provider (IdP). Since you are using a SPA, there are some restrictions on which flows you can use. A SPA can't act as a "Confidential Client" which is required for some flows. (Basically - the Client Secret required for the other flows would be visible in the browser network trace, so it's not "confidential".) The "Implicit Flow" used to be recommended for SPAs but it's less secure, so now the "Authorization code flow (with PKCE)" is recommended. Steps 2 & 3 in the question above are when you are executing the flow to acquire a token.
The authentication flow doesn't really address how you save and send the token to the API (#4 in the question), but the Microsoft Authentication Library (MSAL) helps with that - More information here - https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-spa-overview
In Azure AD, you'll want 2 App Registrations - one for your SPA and one for your API. The API App Registration will need to "Expose an API" which really means to define a scope. Your SPA App Registration will need to Add an "API Permission" to the scope you defined from your API App Registration. (It will show up in My APIs.) This relationship is how #5 in the question is enforced.
Many of the steps for setting up authentication in Azure AD and Azure B2C are similar but Azure AD is designed for authenticating users that are part of your organization. Azure B2C allows you to build a set of users that aren't members of a particular Azure AD organization.
We are trying to use Azure B2C for a use case where we did not find much information. The idea is that several partners, each with their corresponding IdPs, will embed in their web and mobile applications our platform.
This platform can be consumed via API or via WebView, depending on the maturity of our partners' applications. Partners want to federate their IdPs with our Azure B2C with OIDC.
The problem comes with the user experience that we are proposing. The user is facing a double login with the same credentials. One time when entering the partner's app and a second time when entering the tab of our functionality inside the partner's app (our B2C redirecting by OIDC to the partner's IdP).
Is it possible to do this flow without the user re-entering his credentials inside each partner's app to access our services?
We have a scenario where in mobile app(Xamarin Forms IOS APP) logs into the Azure ADB2C and generate a JWT token if the user is a valid user(user is configured in Azure AD B2C). We have a requirement where in, we need to generate a token based on the role i.e. based on the role with which user logs in, we want to generate a token and that token we are trying to use it in subsequent Web API calls.
Articles which we found out on this particular scenario was having web application as a client where in some mechanism of secrets were explained. In the mobile app client scenario, its not possible to have a secrets.
Followed the below mentioned article, but couldn't get any concrete information also
https://codemilltech.com/adding-authentication-and-authorization-with-azure-ad-b2c/
Any pointers on this particular scenario would be very much helpful to us.
Thanks!
There is no out-of-the-box support for RBAC / Roles in Azure AD B2C. However there are a lot of samples in the official GitHub repository. For example the "Implementing Relying Party Role Based Access Control" by this method you can add the groups to JTW token and also prevent users from sign-in if they aren't members of one of predefined security groups.
After a lot of searching, most of the scenarios moves all the authentication to Azure AD and WebAPI just has to know how to read the token. (To achieve this we are using Azure AD middleware in OWIN pipeline). Also, this means that any client that wants resources from the WebAPI has to authenticate to Azure AD on their own (For example: adal.js for JS). Lets say my I want to keep user info within my WebAPI. I suppose I can easily just Create/Read users using some unique field in Azure AD JWT token and I do not need to worry about token validity or any other stuff about security since this middleware does that for me. Simply, I can just use it.
And here comes the mystery that I can not understand.
What if my WebAPI requires specific claims that Azure AD does not provide. For example authorization (permissions and so on) or even organizationId (in multitenant application).
Azure AD works as external identity provider, same as Google, Facebook and so on. But the difference is that most of user authentication logic lives in WebAPI (at least with the examples you can find). Client application receives a list of external providers a WebAPI supports and that is it. This gives an opportunity to introduce LOCAL AUTHORITY tokens with the claims WebAPI would need. But it kind of means that you start creating your own identity service within WebAPI, you also have to manage refresh tokens and so on.
Does it mean that the proper solution would be to start using IdentityServer that integrates variety of external providers and manages token creation with specific claims that my WebAPI would expect?
I understand that WAAD is meant for internal organizational accounts. I understand the concepts behind ADFS and other "AD in the cloud" related topics. But is there really anything that is preventing WAAD to be used for public accounts?
I want to build a public facing web site using ASP.Net MVC. I will use WIF to implement claims authentication and plan to use ACS as a claims federation provider. I want to allow the end users to login using Social Network Accounts (out of the box with ACS). But I also want to allow users to register their own user name and passwords for my web site. Can I use WAAD for this part?
Of course I could build my own custom STS. Or I could use Thinktecture IdentityServer for this purpose. But there are some clear advantages of sticking with WAAD:
simplicity (to set up WAAD as a STS to ACS takes just few clicks)
performance, security, reliability guaranteed by Azure SLAs
Is there any disadvantage to this approach?
You certainly can use WAAD for creating user accounts. You, also of course, have to force users to use e-mail style logins.
There is however one (BIG in my opinion) disadvantage of WAAD against ThinkTecture's Identity Server: WAAD does not have a user registration / password management / password reset flow.
UPDATE (29.07.2014)
Today WAAD provides Self-service-password-reset as part of Premium Features. However still no self-service-user-registration. Frankly I do not expect to ever see self service user registration, as WAAD is targeting enterprises, and not your specific scenario.
To implement mentioned flow in WAAD, you have to developed your own MVC App from scratch, that uses the Graph API for all mentioned scenarios.
On the other side, you have Identity Server, which has thousands of downloads, which is developed by the Gurus of Claims based authentication and security. Identity server has very rich and easy to use extensible structure. While it also does not provide the user registration and password reset flows out of the box, it is already an MVC 4 application with very rich extensibility points.
Setting up an Identity server for run in Azure is also extremely easy. And setting up Identity Server as Identity provider in Azure ACS is just couple of clicks on the management portal.
You say that WAAD is SLA backed, highly available, etc. But your Identity Server deployment on a Cloud Service will be SLA backed too if use at least 2 instances of a Web Role.
If I have to chose whether to extend Identity Server to support user registration etc, or to create entirely new application from scratch that uses WAAD GRaph API for that feature - I would use Identity Server.
As of September this year the Azure B2C preview is there. This should satisfy the scenerio of self service user registration and different identity providers (Facebook, Google, Microsoft...). These are all serviced from AzureAD.
Azure AD b2c
There is als a complete MVC sample available
Azure AD b2c MVC Sample