I found that to authorize the applications I can also add a client application in App registration>{my api}>Expose an API. I tried this method and the method mentioned here:
API Permission Issue while Azure App Registration
both work, What is the difference ? Is one better than the other?
If you add your client app in Authorized client applications, when your client calls the API, they will not need to consent. If you use another way, after you add the Delegated permission/Application permission, the user needs to consent to the application(if the permission is admin-consent needed, you need to use admin consent).
The one is not better than the other, they meet different requirements. As the statement said, if you want this API trusts the application, you could add your client to the Authorized client applications, then users will not be asked to consent when the client calls this API.
For more details about consenting to applications, see this link.
Related
I have created a Microsoft Teams bot built using a Golang port of the Bot Framework. It is a multi tenant bot which lives in my infrastructure.
It is easy to add the bot as a "Teams Application" by selecting it from the marketplace (for free), however, to function correctly it needs additional Microsoft Graph permissions. Specifically read the title of a MS Teams Channel / Group Chat.
This seems to be a challenge for users as almost no one - even those 'in IT' seem able to correctly add the permissions required, even with documentation.
I've been helping them personally but it's not a commercial product so not viable in the long term.
I would like to find an OAuth2 flow which would allow a privileged user to authenticate with their Azure tentant and grant the necessary privileges for my application to do it's thing. Or, alternatively create the client registration in advance of installing the bot.
Every OAuth2 flow requires me to have (or know) my client_id before making the request. Given it's in the users Tenant, I don't have access to it; the users can authenticate against their Azure AD tenant though, so they must receive a bearer token which would allow them access to create or update permissions on an Azure Application.
There is chance to use the OAuth 2.0 client credentials. This grant is specified in RFC 6749. This grant is to access the web hosted resources. This resource will directly identify the application based on the identity of the application. In server-to-server communication we can use OAuth 2.0. This can be referred as "Service accounts" or "Daemons".
Microsoft identity platform and the OAuth 2.0 client credentials flow
please, is here any way how to make relationship between applicaiton in Azure AD and User with client secret.
My use case. User ask for token with client secret(as deamon) and call my web api and a verify this token. Token is valid but there is no information about user who call it or who registered app. User gets token via API (https://learn.microsoft.com/en-gb/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token)
When user ask for token interactive everything is ok.
I tried to use a information about who created app, but Azure AD does not set it when user is administrator.
Is there any way how to use deamon which will be connected with some user?
Is there anywhere i can save this relationship in azure AD?
My idea, every user who wanted use my web api as deamon create his application and connect to mine web api, which use his app for verification. Relationship between app creator and user can be enough. but when i delete user and he has still client secret, he can access. I dont want to use his username and password because it will be saved on different computers and it is not save enough.
If you have more questions, dont hesitate to ask!
Thank you for any idea.
For scenarios, such as this one, your application should have an App Role with the allowedMemeberTypes having Application and as mentioned in the docs, this will show up as an application permission to other apps.
So the consumers of your API will have to add this application permission to their daemon app (which requires admin consent). This will trigger a flow internally that creates a Service Principal (like a user persona of the application) and adds that as a user to your application (you should be able to see it listed under Enterprise Applications > (Your API) > Users and Groups).
When you want to deny this daemon access to your API, you will just have to revoke the admin consent provided at first.
I believe you could even automate this process by using the Microsoft Graph APIs.
I have got a scenario where I would like to retrieve calendar bookings/meetings from Exchange using Graph APIs. These meetings should only be available in the application running on control/touch panel located in that room. In order to do that, I have registered an App in Azure AD and using MSAL's .NET PublicClientApplication with necessary API permission i.e. Calendars.Read which requires Admin consent and I am using Device code flow in the application which generates a code whenever I try to run the app.
I see that it's also possible to configure a ConfidentialClient which acts on behalf of application and not the user. Also, this requires a pre-consent from Admin.
Question :
Not sure which type of authentication mechanism is best suitable in this Scenario ?
Is it possible to make API permissions for e.g. "Calendars.Read" to work for a specific account? Like in this case just for that room
Not sure which type of authentication mechanism is best suitable in this Scenario ?
I think both of them could meet your requirement, for the security, I recommend you to use the option one. Something you should note, if you are using the delegated permission Calendars.Read with auth code flow, the user need to log in the App, then the app do operations on behalf of the user, essentially the permission comes from the user.
If you use the application permission Calendars.Read, it uses the client credential flow, the permission comes from the application, it means everyone in the room can use the application to retrieve calendar bookings/meetings.
Is it possible to make API permissions for e.g. "Calendars.Read" to work for a specific account? Like in this case just for that room
No, you could not make the API permission to work just for a specific account.
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).