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.
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?
Current State: I have a mobile application that signs users into Azure AD via OAuth using the PKCE flow. Once authenticated, the app uses a token to get various forms of data from some APIs.
As the application has evolved, the need to integrate SSO with another web application has come up (and there will be further service providers added as we move forward). It will act as a service provider and it supports IDP initiated authentication via SAML.
Question: once this service provider is configured under the AD tenant, is there a way to exchange or translate our OAuth token for something that can be passed on to the the SAML SP without having to re-authenticate? Am I even thinking about this in the right way? I'm mainly curious if we will need to re-implement authentication in the mobile app to support SAML (i.e. stand up some sort of web-based SAML service that can act as a proxy for the mobile application)? If that route is a necessity to accomplish our requirements, I'm assuming there's a way to still get a valid OAuth or equivalent token we can use to send to our APIs.
Apologies if this is a repeat question, but I couldn't find anything with similar specifics. Thanks in advance!
You can surely use the OAuth 2.0 OBO flow that allows an OAuth2-based application to access web service API endpoints that consume SAML tokens. You can read more here and it has some really good guidance on how to achieve the same:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow#saml-assertions-obtained-with-an-oauth20-obo-flow
Make sure that you SAML request is well formulated per the details mentioned here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-sign-on-saml-protocol
I have an existing API Management service that I have enabled REST APIs with. The API management services comes by default with a developer portal where people can register to use our APIs.It looks something like this.
As you can see, you can register here but also sign in. This API management service by default uses basic authentication to move you forward. After looking at the docs for API management service, I was not able to find anything that would help me replicate this so I can use APIs to make the same /register or /login calls.
My question is, how can I use my own Angular app to make API calls with a simple username/pw to allow user registration and login against API management service?
See here https://learn.microsoft.com/en-us/rest/api/apimanagement/2019-01-01/user/createorupdate for an API call to create a new User in API Management.
There are two ways to address APIM management API. The default and most commonly used way is through ARM (https://management.azure.com) this way you only will be able to use ARM auth and will go through usual RBAC checks before you're given access to any operation.
If you're aiming towards how dev portal itself uses APIM management API then you need to follow this guidance: https://learn.microsoft.com/en-us/rest/api/apimanagement/apimanagementrest/azure-api-management-rest-api-authentication. On one thing this allows you to create SAS token and call management API directly (notice that hostname in base URL is different), but more interestingly, once this API is enabled it becomes possible to call it anonymously as well. Of course only data you expose to anonymous users through dev portal is available this way.
More interestingly though is that it opens possibility to make Basic auth calls to such management API. Anonymous user could make call to any endpoint with Basic auth token based on user email and password and be authenticated this way.
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).