I am creating an iOS app for internal use. We have a Google Domain. As part of the functionality of the app, I want to be able to search for all users in that domain. This can already be done in Gmail, the Apple Mail app, and others.
I found that you can use the Admin SDK for users.list to do exactly what I want to do. I created a Client ID for the iOS app and authorized my app to perform users.list.
However, now I get a permissions error for users who sign in with OAuth2:
I found that you can create a service account to make API requests on your behalf if you delegate it to have the authority. I'm not sure if this is what I want to do since this seems more like something for a secure server to do rather than an app. I'm also not sure how this integrates with a user (from our domain) who signs in with OAuth being able to list our users.
Is it possible to list/search the users in a Google domain purely through OAuth / frontend app?
Aside from caching your own list, I think there are two ways to give users the ability to list all users:
A. Undocumented call to this GAL API:
https://www.google.com/m8/feeds/gal/your-domain-goes-here/full?alt=json (source). You can test this in the Google OAuth Playground by selecting the scope for the Contacts V3 API or using the string https://www.google.com/m8/feeds/.
B. In the Admin console, create an "all users" group. Assign to a newly created Admin Role. Grant the admin role "read" in Privileges > Admin API Privileges > Users > Read (checked).
Related
I'm building an app that shows users people they might be interested in talking to. If a user says he's interested in a person I show them, I want my app to create this person as a contact in my user's SalesforceIQ.
How do I do this? I see from the API documentation https://api.salesforceiq.com/#/ruby#documentation_contacts_create-a-contact that I can create a contact if I know my user's username and password, but of course I don't want my users to give me this information. Is there some way for the user to OAuth or whatnot by clicking a button that authorizes me to add things to their SalesforceIQ?
The SalesforceIQ API uses HTTP Basic authentication and does not currently support OAuth according to their documentation.
For a SalesforceIQ user to grant API access to your app to create contacts and for other privileges, the SalesforceIQ admin creates an API Key and API Secret for your app which is then used for the HTTP Basic authentication username and password. This way no user needs to provide your app with their credentials. This is configured in the SalesforceIQ admin UI under Settings > Integrations > Create New Custom Integration.
For the admin to provide these credentials to your app, you can have a UI where the SalesforceIQ admin enters this for your app to store and use with the API for their account.
This is described in the following places, briefly in the API Reference and in detail in a Help Desk article with screenshots of what the SalesforceIQ admin needs to do:
API Reference: Requesting Access
API Reference: Security and Authentication
Help Article: Set up API access
So I was following the below (classic) tutorial for spring boot with facebook:
https://spring.io/guides/tutorials/spring-boot-oauth2/
Everything is working fine, however I can't find documentation to help me implement my specific use case. So here it goes:
I'll have two facebook apps: one for the owner and another for the regular user
These two facebook apps will ask for different permissions (ex: for owner app it'll ask for permission to post in the fanpage and for the regular user it'll only for basic user info)
There will be two real application being one mobile (iOS and Android) and another browser based application (that's not really relevant)
REST API will be secured based on roles, meaning that the owner will have the OWNER role and the regular user will have the REGULAR_USER role, so that, for example, the regular user won't be able to call the API to post on the fanpage
Both applications will make it possible to login with or without facebook, because I need an users table to store more information and so
Eventually regular user can login as owner if he/she downloads the **owner* app
So, to summarize, I need:
Two facebook apps to be backed by same spring boot application
The ability to authorize an user with APP ID X and assign OWNER role and the ability to authorize an user with APP ID Y and assign role REGULAR_USER
To be able to configure (in the YML) two different facebook apps
The user to be able to merge existing account with facebook if he authorizes later on
I guess that's it. I'll edit later if I find more useful information to provide.
Thanks!
There is Dave Syer's project that shows how to set up an Authorization Server and multiple Resource Servers in the same app.
Similar question with solution: OAuth2 SSO for multiple resource servers with spring boot and jHipster
I have an app that currently allows users to enter in a company name and we use the LinkedIn API to pull all the public posts that this company has made on LinkedIn.
The new API rollout has occurred and while I have a difficult time finding the information I need in the LinkedIn API docs it seems that no one can access company info for a company they are not an administrator of.
I am not trying to access company info or to change their page or anything like that, I just want a list of their public posts. I don't require my users to sign in and even if I did I doubt most of them are administrators of these company pages. Is this totally no-longer possible with the LinkedIn API?
The new API rules for Company profiles stipulates:
"New requirement for Companies API
All calls to Companies API endpoints will require the authenticated user to be flagged as an administrator of the LinkedIn Company Page that is the target of the API call. You become the administrator of a page when you create it. If the page already exists, you will have to contact the existing administrator to grant admin access to other LinkedIn members.
Your API call will return a 403 Forbidden error if you do not have the appropriate admin permission to interact with the target company."
Link here.
LinkedIn is making things really tough for everyone. You'll need to apply to be a partner, but even in your case, the admin would have to sign in. Effectively, unless you're akin to a Hootsuite that gets the page admin's rights for the sake of publishing, you're not going to be able to do what you were. Bummer.
I am trying to achieve the following:
an authenticated user uploads a video on my web application
my web app stores the video, logs it in our database etc. then connects to a Google account and makes a request to upload the video to a Youtube channel within that google account
I've created the Google account, enabled the youtube API, configured OAuth 2.0 access etc, but I'm not sure that any of the documented workflows meet my requirements. (For example I don't want any user interaction as part of the authentication process).
It looks like a Service Account ( https://developers.google.com/accounts/docs/OAuth2ServiceAccount ) is what I need, however these accounts dont appear to support all Google APIs, or at least not youtube.
Does anyone have any advice / has anyone implemented something similar?
When you say ... "For example I don't want any user interaction as part of the authentication process", how will that work.
The user might not be logged in to Google, or might be logged in to multiple accounts so will have to choose which account to use for your app. So the potential for user interaction is unavoidable.
Once the user has authorised your app, logged on to your app (ie. accessed it and you've stored his user id in the session), then future accesses will be devoid of user interaction; at least until he logs off.
The difference between service accounts and user accounts is not the auth flow. The difference is that with a user account, the API access is by the user via your app (so the video will be "owned" by the user. With a service account, your app IS the user (so the video will be owned by you).
I'm not saying that Service Account is wrong for you, just that your reason for going that way is not quite right.
Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process.
Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.
Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.
My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??
What are the best practices in such a scenario?
Thanks for any info you can provide.
Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.
You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.