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?
Related
My organization has implemented authorization using Oauth on our APIs utilizing Azure AD B2C. We have different applications registered and have given them app roles that we ensure are on the JWT for authorization, as well as other claims we use for validation.
My question is it best practice to then use our own graph API credentials to handle changes on the backend of our API, or should we be using theirs?
For example, an application wants to edit a user in B2C. They call us with their JWT scoped to our backend API. We validate it and update the user. Should the update be performed using our own graph API credentials, or should we be performing some form of token exchange to obtain a graph token tied to their credentials somehow?
Azure AD B2C doesn't support on-the-behalf-of flow yet for API's. This being said, there is value of this design with complex resource API delegation models. This requirement generally is something that evolves from mature services due to acquisitions or just increasing data points from multiple sources but requires scale architecture.
For simple services that don't have 100's/1,000's of resource API's, then a simpler design (not requiring token exchange) makes sense.
Using something like Azure API Manager is ideally to put in front of your application. This gives you the typical control that an APIM provides. Other things it provides are:
DNS control for API endpoints that are not service dependent
Ability to do fallback logic by controlling endpoints and automation
A/B testing and release controlled by DNS
Requires no application dev change to update endpoints
Depending on industry, you may require/need OBO - for having the authorization Web API (API-1) not obtain user data in the original token - and data is in the 2nd token (API-2)i.e. resource API. Mostly it's a design requirement on how the API resources requires. I'd recommend looking at the OAuth token exchange protocol to see what makes sense for you. It's important to understand OBO does not align with the token exchange protocol.
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'm working with a client to define a security strategy and have got stuck trying to get something working. I'm new to Azure AD so this may actually not be possible.
Consider the following application landscape.
I have 4 "API" applications:
API-A, requires interactive user and role based permissions
API-B, access via service demon, client_credential grant
API-C, must not be authenticated against directly
API-D, access via service demon, client_credential grant
A user / demon authenticated against API-A or API-B should be able to access API-C as well. However the demon authenticated against API-D must not be able to access API-C.
I was expecting to be able to use the "Expose an API" and "API Permissions" of the App Registrations to be able to control to "roles" returned in the JWT, I cannot seem to get it to work or find any decent guide on how this can be achieved.
EDIT: For clarity the API applications are not hosted within Azure, I am just looking to use Azure AD to provide authentication
It may be helpful for you to distinguish between client apps and API apps (or resource servers in OAuth2 lingo). Each of them has to be registered separately. Your list above seems to merge them together, which is a likely source of confusion for you.
The former (client apps) acquire tokens, the latter receive them from the clients with the service request. Authentication is only only involved when client apps acquire tokens. APIs do not authenticate - they use tokens to authorize access to their services. Clients acquire tokens either on behalf of a user - and the user authenticates and consents as part of the process, or on their own behalf (client creds). In AAD an API app may expose/define scopes/permissions which may be included in one or both of these token types. An API may decide not to require any tokens (sounds like your API-C). You Expose (available) Permissions on API apps, you specify (required) API Permissions on client apps. At runtime (if using the AAD V2 endpoint) a client may request fewer scopes than it is is configured with as Required. That applies only if the client is using delegated tokens (user based). (Note that an API app may also be a client app to another API app (common in multi-tier systems).
BTW, where the clients or APIs are deployed is totally immaterial to the above. At most deployment affects the value of the reply url you need to specify for some client apps (not APIs).
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'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.