I am looking to create a login that verifies a user account via the graph api and also verifies they are a microsoft partner via the partner api. I can easily get one grant or the other but can't seem to get both to work in one grant. I would rather not force the user to approve two different app approval boxes.
Is this possible:
scope=https%3A%2F%2Fapi.partnercenter.microsoft.com/user_impersonation%20https%3A%2F%2Fgraph.microsoft.com/openid+profile+email
as per the limitations of azure ad, I don't believe you can request multiple scopes from different external resources like you're doing there. you will have to do two different requests. the token should stack with the resources, but you cannot call them both in one go. so no, that scope= you provided probably won't work or will only return the first scope.
Similar type question for reference.
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1390
Related
I'm testing Azure Graph API.
and I'm trying to find an API that allows me to retrieve only users that are assigned to a specific app I created.
In app registration page, I gave a user.read.all permission, but the get user API gives me all users that are in the AD and not only that are assigned to the app I created. Should I change the permissions? or to access an another API?
Does anybody know what to do?
Thanks
Additionally, This object id should be based on service principal and not the application registration here.
You can retrieve the object Id from Azure AD->Enterprise Applications->Your app->object ID.
You need to have at least Application.Read.All and Directory.AccessAsUser.All for delegated permissions or Application.Read.All for application permission based on user or application context.
For specific details, you can add $select parameter to show only the displayName of the users assigned to the app.
https://graph.microsoft.com/v1.0/servicePrincipals/{object Id}/appRoleAssignedTo?$select=principalDisplayName
As a workaround you can use the below graph API to get the list of users.
https://graph.microsoft.com/v1.0/servicePrincipals/{ObjectID}/appRoleAssignedTo
Note: The above graph API gives the Object Types User and Service
Principle as well
As discussed in the MS Q &A Platform This endpoint currently does not support filters based on appRoleId. In fact, except that the id parameter can be filtered, the three parameters appRoleId, principalId, and resourceId do not support filtering. Similar issues have been raised before.
I have read the documentation on Microsoft.com and have only got answers about giving Applications authorization to talk to eachother but not how to implement a permission system on each different application that I have.
I basically want to know what the best practices are to implement Authorization on my .Net API and Angular Client.
I would use Azure AD to redirect external and internal users to the Microsoft Sign-In Page, I am missing a fine grained Permission system to authorise users to access different Resources on the API or on the Angular Web Application.
Wo I have to set up a DB for my API with permissions?
How do I add new users to my DB after registering them to my AD?
Im really confused here, so my questions aren´t really as clear as I wish I could write them.
Compiling comments to a proper answer:
Per-user permissions are limited to appRoles, roles that you can give in Azure AD to users. You can also use security groups to achieve a similar thing if you want. But anything finer-grained has to be implemented on the app side.
For identifying users you can use one of two claims in the user Id token / access token. oid or sub. The oid is the unique immutable object id in Azure AD. The sub claim is a unique immutable id within your app. So every app gets the same oid, but a different sub for the same user. The oid claim is also used when calling e.g. MS Graph API to identify the user.
Planning on creating a Google Assistant Application that allows our customers to access business data. The problem I am having is understanding how a given user would link his account to his "instance" of our multi-tenant solution. I think the deeper problem is know which Tenant URL to associate with a particular account. I know I can implement the Accounting linking using Oauth, I have just yet to see how this could work with a single Assistant App accessing multiple tenants depending upon account.
You can get additional info from the user, by asking him, and save that in your context, and then you can request for a sign in. this way, during the sign in process, you can use the context to sign in the user into the proper tenant
I'm connected to an API that provides information about cars based on their registration. According to the docs the api can provide both user specific data and general data about the registration supplied.
I am using the connection method which does require specific users data, and therefore does not require me to gain access to any specific users account.
On my end users will visit my application and enter a registration number which I will use to call the API and return all of the information about the car.
Am I right in my thinking that my application is essentially the 'user' as far as the api is concerned, and I will only need to use one access token. I can then use this access token to make multiple API calls (one for each user that searches on my application)?
Or will i need to set up an access token for each user that visits my application and treat them separately.
Only your application making the API requests requires a token, unless the licence agreement/documentation of this car API says otherwise.
As far as your users are concerned, your application is just magically sourcing the registration info from its database.
Suppose I have a working REST API for my product.
I want to give access only to developers who sign up to this product. Also, there will be several plans available so certain parts of the API are not accessible on the free plan.
From the grant types I've seen only the client-credentials one seems to be the closest solution. However that won't authenticate the developer account stored in my product db, it will only get an access token for that client. The user won't actually be 'logged in' per se. Add to that the fact that a single client can be reused by everyone, according to implementations I've seen.
The only way I see is creating a custom grant type, by adding an extra api_key to the client credentials type, which pertains to the developer account.
Is there a way to do this with the existing grant types? Introducing custom types will not work with many oAuth2 libraries out there out of the box and I don't want to give the developers the hassle of modifying them.
I don't think you have to invent a custom grant type.
A single client can be reused by everyone only if everyone knows the client secret.
So, it seems that what you have to do is (1) to authenticate a developer when you issue a pair of client ID and client secret to the developer and (2) to motivate the developer not to reveal the client secret to others.