I have an Azure client application that uses Microsoft graph APIs.
I am using the workflow described at https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow to have admin authorize my azure client application for his tenant.
This flow ends up giving my client application an access token which my client can use to access various resources in the tenant.
Now, my client application needs to find out is 'who' provided the concent. The access token I get does not have this information (unlike in case of other authorization flows).
A tenant may have multiple admins and my application needs to know who among those admins authorized my client application.
What is the best way to find this out?
Thanks,
~ Urjit
my client application needs to find out is 'who' provided the concent.
You want to find the admin that authorize your client app, as I know, there is no way to find out this information about the admin. Because when you consenting permission for your app, you need the admin to do this for your account. After admin consent, there will be no record for this, no matter in token or portal.
Related
We want to use Microsoft Graph for retrieving Business to Consumer (B2C) tenant users details in our code.
GET https://graph.microsoft.com/v1.0/users
It is giving only normal tenant users.
But we want to get all users signed up using sign up and sign in flows along with their usernames.
There is no proper documentation regarding this. Can someone with domain knowledge help us how to achieve this?
If not possible, CLI/powershell also satisfies our requirements.
Please help 🙏
I believe you're running into the limitation described in the note here - https://learn.microsoft.com/en-us/azure/active-directory-b2c/microsoft-graph-operations#how-to-programmatically-manage-microsoft-graph
Delegated permissions for users signing in through user flows or custom policies cannot be used against delegated permissions for Microsoft Graph API.
Notice how you can't grant a delegated permission (for instance User.Read) to a B2C App Registration the way you can to a "normal" Azure AD App Registration. But - you can grant an application permission (like User.Read.All) to your application.
This means you'll have to submit the Graph API request using an auth token granted to your application, not to the user.
My project is a MVC Core 3.1 web application.
The autentication is based on the Microsoft.identity.web template to sign-in users in Azure AD B2C.
You can find the samples here: https://github.com/AzureAD/microsoft-identity-web/wiki#samples
Users can register/login as standard users on B2C or login with the corporate account (azure AD, so an openID Connect Identity Provider).
When Users signs in with the corporate account, I get a JWT token with a claim named "idp_access_token" which contains the access_token from Azure AD. It contains some claims I need for the application (for some reasons I can't even see the emailAddress/unique_name in the B2C token so I need to get it from here...).
But I'm not sure how (and where) I'm supposed to deal with this token and how to access the claims inside it. Can I map them in the claimPrincipal? Because I would like to use the email as the "User.identity.name".
Should I write a service (transient?) and Inject it where I need it?
Sounds like you are using a feature you don’t actually need. Usually the embedded IdP access token is used to call the services that the IdP hosts. For example, a user logs in with Facebook and your app wants to call the Facebook API to post to their Facebook wall.
You as the app developer should not inspect or use the token for your own self, as you cannot trust it. If you want data from that token, then perform the relevant claims mappings in your B2C policy/user flow, as B2C does validate the token and can trust it. You cannot. Services provided by the IdP will verify it, so also can trust it.
I'm trying to figure out how to use the Azure Graph API to query a user's full name (first and last) from a given username. I understand I can do this with the following Graph API call...
https://graph.windows.net/myorganization/users/{user_id}?api-version
However, I am not sure how I go about getting an access token to use with this, because this process will be called without a user logging in, which is usually how we obtain an access token.
Is there anyway I can pass a username/password to a given URL using cURL or something and obtain an access token that way, so it is done behind-the-scenes?
There are two main authentication methods which are supported by OAuth 2:
Authorization Code Grant Flow
Client Credentials Grant Flow
The first flow requires a user agent to be present to sign into the client service and results in a delegated token. The second method does not require a user to sign in, as it only authenticates using the client secret; this results in an app only token.
If you want to create a background service that captures data from the AAD Graph API, you can absolutely do this using the Client Credentials Grant Flow, which does not require a user to be present at any point during the authentication flow.
You simply need to configure your application to to have app only scopes. Read here: Permission scopes | Graph API concepts. App only scopes all require tenant administrators to consent to the application in order to get access to data.
Finally, I feel I must mention that there is another less used flow specified in the OAuth 2 spec: Resource Owner Password Credentials Grant. This flow specifies how a client application who has knowledge of a user's username and password could directly pass those parameters and get an access token on behalf of the user. However using this flow is not good practice at all.
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application. The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
We support this in our V1 endpoint, but not in our new V2 endpoint. You can read this blog to learn more.
I have a scenario where a user has logged into to a web application (authenticated with OpenID Connect) and then needs to access data from a separate REST service.
The REST service needs to determine whether or not the user has permission to access the requested data, but if the user does have permission, then it should grant authorization to the web application without requiring the user to interact with the UI.
Essentially, what I need is a two-legged OAuth solution where the client/relying party is fully trusted but the user, who's already been authenticated, is not.
Going in, I assumed that OAuth could accommodate these requirements, but none of the grant types seem to match the requirements:
Authorization Code is the opposite of what I need, as the user is pretty much automatically trusted but the client is not, requiring that the user grant access to the client via a web form.
Client Credentials trusts the client (which is what I need) but does not give the service an opportunity to determine if the user has permission to the resource (user auth tokens are not passed to the service, making all requests essentially "anonymous").
ROPC (Resource Owner Password Credentials) would appear to be the only option, but requires the web application to know and possibly store the users' login credentials (which is untenable).
Is this a gap in OAuth? Or am I misunderstanding these grant types? If OAuth can't support this scenario, is there another widely adopted open standard that I've missed?
Of note: I only own/control the web application, while the customers (all of which are businesses) own/control both the authentication servers and the REST services. Therefore, a shared, non-proprietary standard is necessary so that our customers will know how to configure their services (IBM, Microsoft, whatever) and so that I'll know how to pass along any authentication tokens, etc.
I think this is possible using normal OAuth2 flows. You have your web application use the code authorization grant to get a token to call the API on behalf of the user.
Your web application makes the call to the API attaching the JWT token in the Authorization header. If the REST service determines the user does not have permission to access the resource, it returns a 401 Unauthorized HTTP response code.
Your web application handles the 401 response by going back to the authorization server and using the client credentials grant to get an access token to call the REST API on behalf of the client itself.
As both grants allow you to get a refresh token, you should be able to switch between access tokens easily.
If there is no trust relationship between the web application and the REST service, there's no way around using the Authorization Code grant since the user needs to be involved anyhow to allow the web application to make the call on behalf of the user.
If there is a trust relationship between web application and REST service you should be able to use the regular OpenID Connect flow to get an access token to the web application at login time that can also be used in calls towards the REST service.
You may pass on the user information as part of a JWT (i.e. a structured) access token that is signed by the web application itself or the OP; that would be OAuth 2.0 compliant. See https://www.rfc-editor.org/rfc/rfc6749#section-1.4 and May an OAuth 2.0 access token be a JWT?.
If I add authentication in Azure Mobile Service with Google as the provider, I go and create an app, get the app_id and secret and plug it in. Great, now users can authenticate with google and get a user token. Now they are considered an "authenticated user" wrt the table permissions.
However, I don't want to authorize everyone with a google account access to my API. Is it possible to limit this to a list of known users? Must I check every request for specific user ids?
Perhaps social login is not the best choice here and I should use something else like Azure AD?
We added custom authentication provider to wams and synchronize the social account with "our" user-account that is stored in the database. For protected web api methods a user account needs to be activated first. You have to check manually whether an account is activated/ high privileged or not and return the result or unauthorized status code.
I decided to use Azure Active Directory to solve this problem. This way, I can create users in Azure AD but not have to manage users myself in the back end. With this choice I am still able to chose the only authenticated users permission level without having to check on every rest endpoint that the authentication users is one of the ones I want to grant access to.