I have a web form that our HR department uses to add new employees. It adds them to the database, inserts them into Active Directory, and a few other things. We would like it to also create their Gmail account and subscribe them to groups (our current users are already in Gmail under our domain).
Everything I find requires OAuth2 for this, yet it seemingly requires a prompt. "Google displays a consent screen to the user".
Is there a way to do what I want behind the scenes without any sort of prompt?
Related
I have an ASP.NET MVC application that is used by different customers. Currently the app is set up to use individual user accounts. I have built some authorization logic around that and would like to keep the logic unchanged.
I got a request that some of the customers would like to perform authentication for their users with their Azure Active Directory. I have uncommented the app.UseMicrosoftAccountAuthentication part from Startup.Auth.cs. I registered the app as multi-tenant in my AAD. I managed to get the whole thing running and users now have the possibility to link their accounts with AAD and use it for authentication.
However, I encountered a few problems I am struggling with:
In order for the user to link his account with AAD he needs to set up an individual login/pass account in the first place. How can I avoid that? I want to have the users either authenticating with login/pass or with AAD, not both at the same time.
I have no control over which account the user uses to authenticate. Let's assume I expect the user to use an account in domainx.com, but if they link domainy.com account it will still work. I need to have some kind of way to compare the expected domain with the actual one that comes back from AAD. How can I do that?
One of the ideas to tackle the problem was to have a customer admin create the user accounts for them. The issue is that in AspNetUserLogins I need to store the user's AAD ID, not the email. How can I query AAD to check the UserID based on the email?
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).
I am thinking to embed google calendar in my website to achieve the following and was wondering if this is doable in google calendar. Otherwise I have to go find another solution.
I have groups of users with one super user, and rest are regular users as follows:
GroupA
Super User 1
Regular User 1
Regular user 2
etc
Group B
Super User 2
Regular User 3
Regular User 4
etc
Each group have their own calendar. Users in each group can not see the other group's calendar. Only able to see their own group's calendar.
Super users of each group have all access to the calendar (add, modify, delete) and have the ability to control how much access regular users have in their group. (read only? read/write etc)
All users are registered to my website, therefore I am thinking to use only one google calendar account (my own account) to create a calendar for each group. Which leads to a question of authenticating my website to google's API. I need the authentication process to be automatic, hidden away from the user and be done on the server side.
My site is built using PHP/Mysql
Q1:
I have tried the Javascript client library provided by google, however it require the user to type in username/password to log into google so that the authentication (OAuth2) process can work. As mentioned in previous paragraph, I only want the user's to log into my website, they do not need to login again into google account. This should be done on serverside.
I even went as far to create a login form with information prepopulated (hidden from the user, the username/password will be visible in "view page source") and send the request to https://accounts.google.com/ServiceLoginAuth, and make the form automatic submit once the user successfully login into my website. However this causes cross domain issues.
Q2:
I may potentially have 10's of thousands of groups registered on my website. each group may have couple hundred users. Can one single google account create that many calendars?
Q3:
Once the calendar is embedded into my website, it seems to be read-only. Is it possible to make it interactive so super users in each group can add/delete/modify events?
Any ideas/suggestions is much appreciated.
Thank you
No answers? It seems like your question is straightforward. If I understand correctly, you want to access calendars from several Google accounts/users. Each user needs to authorize this access, but they only need to do so once. You could generate these requests and send them out via email, for example. When the user grants permission, Google forwards a grant code to your specified callback_uri. The grant code is extremely volatile. It's used to request a token from Google that apparently lasts indefinitely. So there's no requirement that users continually log into Google.
In Google's calendar/simple.php example. The token is stored as a SESSION variable. Even though the token is persistent, the SESSION variable is not. Users have to grant authorization every time the SESSION variable expires. Storing persistent data in a volatile variable is absurd and probably gives the wrong impression about the OAuth2 token mechanism.
I spent a lot of time writing documentation that I couldn't find anywhere else. Please take a look if you think it might help: http://www.tqis.com/eloquency/googlecalendar.htm
What you're asking isn't possible in Google Calendar.
If you're looking to support thousands of groups and each group needs it's own calendar, then you're saying that you'd need thousands of calendars with access control and you'd need authentication to the calendar to be transparent.
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.
I've got a company web app. I have integrated it without much problems with Twitter.
This means, when a staff of our company creates a new product, it posts onto the company's profile on the Twitter web site as well.
However, Facebook is another story. Facebook encourages registrants to sign up as "individuals".
For example, on the registration page:
You are not allowed to put generic emails such as (support#company_email.com, sales#company_email.com)
You may not have the first and last name as a company entity. For example Foo Distribution or Foo Inc
Their automated system simply rejects any clever attempts to register as a "non-individual". With Twitter, it was a breeze. Since Twitter allows / encourages companies to register an account with them directly, and not as individuals.
Moving along on Facebook, I found out that I can create a 'page'. Which I can use for the company. It has the option of allowing other "individuals" to be admin of the page. However, this would mean that each staff would need a Facebook account.
I don't really like this approach, since some of our staff may be negligent with their Facebook passwords. I rather have our web app have one 'method' of accessing Facebook's API isntead, the way it is done with Twitter.
How else would you go about this?
I'd make yourself the admin of the page, install an app that you develop, and then let your users make posts to the page through that app. This way, you're controlling access to the page while letting your users still have access to it.
You'll need to use an offline_access-enabled access token for this to work continuously (permissions documentation), and if that token changes, you'll have to log in yourself and refresh that token (it can change when you change your password or uninstall/reinstall the app). Additionally you'll need a manage_pages permission, and you'll need to use the access_token for your page that you can find in /me/accounts to make posts to the page.