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.
Related
I have created an API that is protected by OAuth using an app registration in Azure.
My app registration does not require assignment, but it exposes a number of roles that the underlying API verifies. To my understanding, this accomplishes almost the same thing as requiring approval.
So far I've only had user/group roles but now I've added an application role intended for integrators, and I want other application owners to be able to request permission to my API. I, as the API owner, would like to review these and either reject or consent to the request. E.g. I don't want everyone to be able to access my API within the tenant without my knowledge, just like all users/groups don't have access with me assigning them to a role.
The Role-based access control for application developers documentation makes it very clear who manages access:
...an application developer defines roles rather than authorizing individual users or groups. An administrator can then assign roles to different users and groups to control who has access to content and functionality.
However, if you create a role with allowed member types set to application, things are not quite as clear and it seems to behave more like a scope, where I give up any access management. Also from my limited understanding, a scope is used when the API needs to request data from the user (e.g. wanting to read their username), whereas a role is used for the application developer to control access to what they are developing.
This is what it looks like when I request access to my API from another app:
This same page mentions the following information:
The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.
As well as:
Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process
However, from my reading, it sounds like this never gives me, as the API owner, any insight into who has access to the API I own. I want to control application access the same way I'd assign a group or user to a role in the enterprise application.
Can this be achieved when it's an application on the other end, not a user? If not, how would I allow applications to integrate in a controlled manner?
I want to explain the feature Azure ad provided to protect web api here.
As you know, we usually use a token in the request header to let the api check if the request had correct permission to visit the api. Such as if the request from an allowed user role, right? So to whole progress should be authentication and authorization. Users sign in first then try to generate an access token to visit an api. Azure AD has similar architecture.
If you had a web application(e.g. web mvc app) you can integrate Azure AD into it then you can allow users use their user1#xx.onmicrosoft.com account to sign in. If you had a web api project, you can also integrate Azure ad and add [Authorize] attribute above the controller so that the incoming request should contain a correct Bearer token which we call it access token.
For Azure AD, we usually have 2 options, verification scopes or app roles. That results from the different flows we used to generate the access token. For example, we use auth code flow to sign in users and generate access token containing scp claim which is granted delegated api permissions. And we use client credential flow to let an application to generate access token containg roles claim which representing it's granted application api permissions. In short, when we set [Authorize] + [RequiredScope(scopeRequiredByApi)] in the controller, it allows requests from a user(user sign in the app and call api), when we set [Authorize(Roles = "roleRequiredByApi")], it allows requests from the application(no user signed in and the app call api by itself).
Here scopeRequiredByApi and roleRequiredByApi is what you exposed and then added to App Registration > Permissions. Just like Integrator you marked in the screenshot, it can be recognized as roleRequiredByApi because its type is Application.
And I'm afraid the roles is not what you want but to be honest what I said is what AAD can do for you... And I think the document I mentioned above about verification scopes or app roles will be a good sample for you.
The App Registration > Permissions section has a great feature for reviewing and limiting the access provided for your app registration:
enter link description here
In addition you should always define the scope of your permissions and limit it to the least required for your app. eg. NEVER set scope at the subscription level! Always set it at the resource group or lower.
Also note that Microsoft now provides Defender for APIs and you can use Sentinel to monitor a lot of the activities related to your app registration. Always always enable logging wherever possible and configure some method of alerting/reporting so you can better understand the activities for your app.
I am designing my first dev tool with the Azure SDK (JavaScript), and I am having a difficult time understanding how to authenticate users in production so the dev tool can access the user's Azure account. The tool is going to retrieve metrics from all of the user's Azure Functions in their tenant to display React component graphs based on those metrics over time. The app will be run locally with an npm run command.
My entry point for using Azure Identity in my app was this blog post (https://devblogs.microsoft.com/azure-sdk/authentication-and-the-azure-sdk/). I like the way the DefaultAzureCredential is working in development, using the tenant for whichever developer is running it by using the AzureCliCredential. I want a similar functionality for production, but for the browser instead of Azure Cli. In other words, if a user is already logged in to Azure Portal, it will get a credential for their tenant. How do I go about this?
One of the things I tried was opting into the Interactive Browser of the DefaultAzureCredential as described in that blog post. But even though, I could see the browser method in the src (https://github.com/Azure/azure-sdk-for-js/blob/main/sdk/identity/identity/src/credentials/defaultAzureCredential.browser.ts), I couldn't figure how to opt into this when using the actual SDK. I couldn't find that method in the npm package in Azure Identity, and the documentation (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/defaultazurecredentialoptions?view=azure-node-latest) didn't help me either. If this is the correct option for my use case, I would like to understand how to opt into it and use it.
Another thing I tried was implementing the InteractiveBrowserCredential. As long as I pass in a redirectUri with a port not already being used by my app, it did open another tab to tell me to login to the Azure Portal if I am not already logged in. This is exactly the user experience I would want in my app. However, after logging in the credential didn't actually do anything. The credential returned actually has a client Id equal to the application Id (04b07795-8ddb-461a-bbee-02f9e1bf7b46) of Azure CLI (https://learn.microsoft.com/en-us/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in) for some reason. This led me to look into the Interactive Browser Credential and find out that it is using the Authorization Code Flow (https://learn.microsoft.com/en-us/javascript/api/#azure/identity/interactivebrowsercredential?view=azure-node-latest). This flow doesn't seem right for my use case, since I have to register my app. I am not trying to grant users access to my app, but access to their own Azure account. Is InteractiveBrowserCredential what I should be using?
Next, I looked into all of the different authentication flows. None of them seem quite right for my use case though. The closest one I found was the client credentials flow (https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow) since I am authenticating the user to their own Azure account and not my app. However, even this one doesn't seem quite right because when I looked up how to implement that flow with Azure Identity (https://github.com/Azure/azure-sdk-for-js/blob/main/documentation/using-azure-identity.md#clientsecretcredential-and-clientcertificatecredential) I found out that I have to pass in the tenant Id. But the app won't know the user's tenant Id of the user before they log in. Which flow is right for this use case?
It seems like there is a gap in my understanding. How can I use the Azure SDK to implement an authentication flow that authenticates the user to their own Azure tenant (not authenticates them to my app) through the browser?
Thank you ShwetaMathur for answering this question in Q & A. Posting the same here to help Stack Overflow community members.
To access your application by Azure AD users, your application should also need to register in Azure AD.
Once your application is register, you can acquire the access token based on different OAuth flows which is needed to call various resources(Users in your case) or protected API based on your scenario.
Azure Identity TokenCredential provide various flows to obtain an access token based on different scenarios.
InteractiveBrowserCredential is one way to launches the system default browser to interactively authenticate a user and obtain an access token.
Using access token, you can retrieve user’s info or access any other resource in Azure tenant. The InteractiveBrowserCredential uses Authorization Code Flow to authenticate users for browser based applications and to access resources further.
Client credential flow is OAuth flow commonly used for server-to-server interactions that usually run in the background, without immediate interaction with a user and help to acquire the token and call protected web APIs.
Complete reference
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'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).
I am trying to have two applications(app1 and app2) in Azure
AD B2C, which is configured for Web api and another application that is configured for mobile app.
I need my mobile app to talk to app1, get the access token, using the app1's application-id and scope. Then use the access token got from app1 to communicate with app2. I enabled SSO in tenant level in the policies but it still says "Authorization denied" for the access token provided.
How can I reuse the access token got from one application to be used in another application.
We have been trying to get through this limitation (or function as designed for security) of B2C AD from weeks.
However, Microsoft does not support it.
We did not want to display MS login page to mobile user on mobile login screen (UX gets compromised). But MS says there is no way possible to avoid it. See response from MS on support ticket.
For more information: Azure AD B2C: Requesting access tokens
You will also benefit reading authentication scenarios supported. We are after something similar to this what they call "Daemon or Server Application to Web API".
In this diagram, Server Application = to mobile application in our case. However you will notice that in this scenario it is assumed that the user is already authenticated (via interactive flow).
We tried to act smart, thinking we can write a Auth web API which mobile will hit to obtain token and then pass this token to our business logic API (secured by B2C AD). We obtained access and refresh token somehow, however the test web app (mobile app) when pass this access token to our business logic API, it fails to validate the token. B2C AD comes fighting for it. Our analysis is not yet complete.
However, I am certain what we are trying to accomplish is not supported in B2C AD.
Hope this helps (I would actually advise you to look for other solution). I will be happy if someone can suggest a way to solve this obvious business problem.