We're looking into Azure AAD B2C since we offer bespoke applications to a number of users. We've chosen B2C since we're after 1 user repository but these users can span across a number of domain applications
It's my understanding that AAD B2C is just a IdP and isn't concerned about user claims.
I am confused though, since we're supporting N number of applications with this single B2C instance, where does Authorisation sit?
With the app? If so, I assume my users will authenticate with AAD, get a token, and then use the said token to call an API / APP? Won't each request require a round trip to the database to see if said UID (User Id) can do said action?
Some of these domain apps could be SPA's, others could be API;s others could be simple MVC applications
You can make a rest api request during authentication to fetch an attribute containing the users roles. Then the app/api can just examine that.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-api-connector-token-enrichment?pivots=b2c-custom-policy
Related
We have a SPA (angular) deployed which authenticates against an azure AD B2C and retrieves tokens that are then used to call some rest APIs.
Now I've been asked to call some other APIs (not under our control) protected by another azure AD B2C (again, not under our control). I don't think that there is any way to "federate" the two AD B2C.
Moreover I don't know if there is a way to obtain access tokens from an AD B2C using some hidden credentials (let's say a technical user/password defined on the second AD B2C) which I wouldn't use in the SPA for obvious reasons but then I could use my authenticated APIs as a proxy to obtain the token from the second B2C and then call the external APIs with the obtained token.
Am I missing something or I've been asked something not feasible with Azure AD B2C?
Your SPA can't easily have a direct security relationship with 2 independent Authorization Servers (or sets of APIs). Sounds like there are some security boundaries here that would be better managed by your back end APIs, which can keep secrets, unlike your SPA.
A useful pattern sometimes is to design 2 levels of API such as this:
Online Sales SPA is running for a user in Western USA
The SPA calls an Online Sales (Entry Point) API hosted in Eastern USA, 3000 miles from the end user
The entry point API aggregates calls to core APIs with low latency, since they are all hosted next to each other
The entry point API can also deal with security boundaries, such as forwarding calls to the new set of APIs
Personally I like your proxying suggestion, but I would not do it in a Core Microservice - I would instead assign this responsibility to an Entry Point / Aggregate API as above. This results in an extra layer, but only requires simple code, and you avoid adding complexity to any other components.
The only solution I've found would be having the supplier of the second azure AD B2C declare a new app registration in their B2C and:
under "Certificates and Secrets" they would add a new Client secret (which they would share with us and that would need to be recreated at least every two years)
under "API Permissions" they would need to specify which APIs (via scopes) can be accessed with the tokens generated using the client secret above
Then we would invoke our authenticated APIs (protected with the token obtained from our B2C via an interactive oauth flow) and the APIs would act as a proxy by calling their APIs after we obtained the token via the client secret.
All this could be done with different API containers with an API gateway in front of them for a cleaner architecture so that our core APIs are separated from the proxy APIs.
Does anyone know a better solution?
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.
I'm designing a single-page app (SPA) and API that will support multiple tenants, including in the same client browser. Imagine an experience similar to the Azure Portal, where users can switch between identities that they have signed into Azure AD with, except that in this case I'm using Azure AD B2C. All sign-ins happen via a single Azure AD B2C instance. Importantly, the tenants do not necessarily have to be aware of each other since they are white-labeled -- the user might be redirected to https://multitenant.app/tenantA and sign in via B2C, and have a totally different experience when directed to https://multitenant.app/tenantB and signing in via B2C there. The two tenants do not need to share data between themselves on the client.
How might I go about:
1) designing the client so that requests to https://multitenant.app/tenantX are directed to Azure AD B2C in a way that enables sign-in using the rules for tenantX, and
2) designing the client so that the MSAL.js library correctly provides a token store containing tokens specific to tenantX when the user has navigated to https://multitenant.app/tenantX in the browser?
Currently I'm expecting to need to intercept requests to the backend API on the client, determine if a redirect to B2C is necessary first in order to sign in to the tenant that the request is for, and attach the appropriate access token for that tenant to the API request. (All this is assuming that I use the Implicit Flow so that I have the access & refresh tokens available on the client.)
Does this make sense? Is there a better way? I've debated using session cookies issued by the server so that the browser handles the "intercept-requests-and-attach-credentials" aspect of this, so maybe that's an option that would avoid the need to maintain all these tokens on the client?
And how does this work when the client signs into B2C? Can I tweak/disable the B2C SSO capabilities sufficiently so that a single user agent (browser) can still obtain multiple different tokens (for different identities)?
The approach needs to be a bit different. This is how Microsoft do it with their "tenant picker" in the Azure Portal.
We hold a mapping of in which tenants your account lives in
We then list the tenants in a tenant picker UI in the app
When you switch tenants, we do an SSO authentication to the new resource (ie the selected tenant) to get a token to it
We use the new token to evaluate your rights in this tenants subscription
To translate this in AAD B2C you can:
Hold a mapping of identifier to 'tenant'
On authentication, call your API to get a list of tenants. Use this sample to list the tenants in the authentication flow
The user selects the tenant, or maybe you do it like Microsoft and have a default preference, in which case the step above is skipped using a B2C precondition. This way the user only goes through selecting a tenant in the auth flow once. Afterwards they use an in-app tenant picker (read on...)
The token issued to the user has the tenant inside it as a claim, this will then be used to do authorization when this token arrives are your API.
In the SPA, now render a tenant picker, use the same API as used in step 2 essentially
The user can select a new tenant in the SPA, use id_token_hint (example) to seed a new B2C user journey with the selected tenant. The user will get SSO through this journey and get a new token with the new tenant inside it as a claim.
I have a 2 application using a single AD B2C tenant. I want to logout the user from both websites when the user signs out to either one of them. I'm using email for local accounts.
In AAD, there is a LogoutUrl registered on each application which receives a GET request to users currently signed in to. Source
I wonder if there is workaround for AD B2C like in AAD.
PS: I am using this repo as reference.
Azure AD B2C doesn't support Single Log Out and we weren't able to find a workaround.
I've understood that in B2C scenarios Microsoft has assumed that IdPs are "social-media" type and considered it is not of end-users interest to be logged out of Facebook when they log out of some service to which they've authenticated via Twitter. Makes sense in that scenario.
However, in government-provided IdP scenarios it is usually a hard requirement to be able to support SLO.
We considered it to be more of a limitation by-design in B2C than technical, so we moved to using another authentication service provider that supports SLO. Apparently a wise choice as I haven't at least heard anything regarding SLO and Azure B2C as of today.
According to the documentation that is possible:
When you redirect the user to the Azure AD B2C sign-out endpoint (for
both OAuth2 and SAML protocols), Azure AD B2C clears the user's
session from the browser. However, the user might still be signed in
to other applications that use Azure AD B2C for authentication. To
enable those applications to sign the user out simultaneously, Azure
AD B2C sends an HTTP GET request to the registered LogoutUrl of all
the applications that the user is currently signed in to.
Applications must respond to this request by clearing any session that
identifies the user and returning a 200 response. If you want to
support single sign-out in your application, you must implement a
LogoutUrl in your application's code.
The suggested answer was from 3 years ago.
Please have a read here.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-custom-policy#single-sign-out
Apparently, B2C does support single sign out, but I could not get it to work despite following the steps and I'm looking for answers on SO.
I'm comparing the new AD B2C features with the social authentication ability in Azure web service. Using the AD B2C approach I can't seem to find a way to do access the underlying access token from a social provider like facebook.
E.g. in Azure Web Services social authentication there was an http://example.com/.auth/me endpoint that would provide BACK the token to access the social provider's api.
Is that not available in B2C? If not that seems like a step backwards.
From what I can see, the answer is no (although I wish there was a way).
See this:
https://blogs.msdn.microsoft.com/appserviceteam/2016/06/22/app-service-auth-and-azure-ad-b2c/
OAuth Tokens: With Easy Auth, the application code has direct access to the provider-specific OAuth tokens. This is useful if you want to make graph API calls on behalf of the logged-in user (for example, calling the Facebook Graph to post a photo to the user’s timeline). B2C, however, does not expose the provider OAuth tokens to your application code.