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.
Related
I want to authenticate users to my nodejs app via Login with Microsoft but I don't want access to any of their AD data other than read access to email and first name.
I know I have authenticated to apps via my work MS account and that app has not been "registered" in my company's Azure env. I have even used apps that do request access to my Calendar (Graph API) and I can grant it without that app being registered.
How does this work? Is it possible to just use MS as my identity provider for authentication without my app being registered?
In order to authenticate a user, a client ID is required.
This must come from a registered application.
There could be a situation in which another application is just using a client ID of another application (in case redirect URIs are able to match).
In the general case I would say that you must register an application.
I want to set up an OAuth2.0 flow for users that have access to GCP.
The user will login to a web app.
Then, the OAuth2.0 flow will need to ask for the consent that will allow the app to perform things on their behalf, based on their permissions.
Therefore, the scopes that need to be requested should be those that cover their actual permissions on GCP.
Is something like that possible when it comes to OAuth2.0 and GCP?
Had you seen? https://developers.google.com/identity/protocols/oauth2
Looks like that might address your question.
Separately from that link --> Yes that is something that could be done. You login via OAuth, and once authenticated that service can use GCP Service Accounts https://cloud.google.com/iam/docs/service-accounts to work with GCP Services.
A user can be granted permission to impersonate a service account.
A service account can be granted permission to impersonate a user account via Domain Wide Delegation (Google Workspace).
A user cannot impersonate another user. There is no mechanism to grant the required permissions.
In a GCP project you can access Google APIs using these types of credentials:
API keys
OAuth 2.0 client IDs
service accounts
So, to answer you question, using OAuth 2.0 in GCP is certainly possible.
However, without knowing what data your application needs to access, it's hard to tell if it's more appropriate to use a service account or an OAuth 2.0 client. In a GCP project, if you go to APIs and services > Credentials > CREATE CREDENTIALS > Help me choose, a wizard will guide you through the process of creating the most appropriate credential for each authentication scenario:
Lastly, when you say this:
for users that have access to GCP
Do you mean that these users have a Google account that can access the Google APIs used in your project? If that's the case, and your project doesn't need to access user's data, then a service account might be a better choice than an OAuth 2.0 consent screen. I think you could let a service account impersonate a user via Domain Wide Delegation, but please keep in mind that Google itself discourages this feature.
See also Create access credentials.
I have been working a while trying to find out how to connect multiple tenants to the same Azure APP to access graph. I end up using ConfidentialClientApplication because I have a daemon service which can't ask for authentication all the time, so tenant admin grants permissions once to my Azure app and I able to access tenant's data with MS Graph API.
I need help understanding whats wrong with the following scenario:
Consider we have 2 tenants: tenant1, tenant2. Both granted permissions to my app. But this means tenant2 can access tenant1's data by specifying tenant1 authority like https://login.microsoftonline.com/tenant1 and email. How to overcome this situation security-wise, should I use one azure app per customer, may be some other MSAL authentication flow for daemon apps? Totally confused.
If your customers can control the authority your daemon app uses, it sounds like you cannot use the approach of a single app with app permissions to all customer tenants.
This approach can be used when you have a multi-tenant app with a background process that runs in your infrastructure that the customer cannot control.
Either your app needs to talk to infrastructure that only you control, which then uses the app permissions, or you need separated applications.
An application would need to be created as a single-tenant app in each customer's AAD.
Either they do it, you do it, or you provide a script to do it.
Then they can enter those credentials into your app's config and start using it.
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.
Following these instructions on implementing client credential flow, using this sample repo to test on, I got a running version of an app using client credential flow that can read email, calendar, contacts.
However I need to sign in with my O365 tenant admin every time I run it and grant access to the application to read emails, calendar, etc.
Isn't the whole point of Client Credential Flow (app-only) that I shouldn't need to enter any credentials to read data, since I've created a certificate that connects my AAD-app with my web-app.
The only thing I can think of is that I have to sign in with the admin just once to set it up properly, but then it makes no sense that I get prompted to login as admin every time I run the application (running on localhost).
You have to run admin consent once, then that should give your app the access it needs with just its client id and secret. Now this only matters to application permissions obviously, if you are using delegated permissions, those always require a logged in user.
To give admin consent, you will need to hit a URL like this in Azure AD:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=your-client-id&redirect_uri=https%3A%2F%2Fwww.company.com%2Fazure-redirect%2F&response_type=code&prompt=admin_consent
Replace your-client-id with your app's client id, and the redirect URI with a reply URL registered for your app (URL-encoded of course). It should prompt you with something like "Do you want to give app AppName the following permissions? No one else in the organization will be asked." You can also replace common with your tenant id or domain name.
You can use the Azure AD Graph Explorer to check if the consent was passed successfully. Check servicePrincipals, find your app, and then check oauth2PermissionGrants and find the objects with your service principal's id. That will tell you what permissions have been granted and on what resources (the Graph API etc.)