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.
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.
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
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.
I am working to build an application which would be able to create custom audiences for many of our clients for facebook ads. I came to know that the most suitable access token for this purpose is system user token (correct me if I am wrong). To get regular user access tokens, we can make a user go through the traditional oAuth flow, I am looking for something similar to get system user access token. How can I get it for any of my clients? Thanks
You must create your system users in the Business Manager of your company:
https://business.facebook.com/settings/system-users?business_id=<YOUR_BUSINESS_ID>
Once you create a system user, you can generate a token for him associated with a given app.
Meanwhile, on your business settings (as stated in the docs) you can request access to an ad_account.
Request Access to an Ad Account: If you request access to an ad
account in Business Manager, the admin of that Business Manager can
grant you permission to work on it.
Once your client gives your Business permission to work with one or more of their ad_accounts, those ad_accounts will appear in your Business Manager. (menu on the left).
At that point, when checking the profile of your system users, you can click on assign assets to give the system user access to pages and ad_accounts.
The token you generated for the pair [system_user,app_id] does not need to be reissued to reflect the addition of assets to which the system_user has access.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.