When using the Graph API normally you first ask the user to sign in. I want to have a user master that has access to read/write the calendars of all other users in the tenant (this is already done).
I want the credentials (userName and password) of master to be stored in my app (webconfig) so that I can make calls to an endpoint that edits users calendars using the master user, without any manual sign-in.
Since MS Graph is an oauth based application, what you are looking for is called App-only access. This is described in detail here. https://graph.microsoft.io/en-us/docs/authorization/app-only.
The advantages of this is that as new users get added or their password change you don't need to update your configuration. In addition, it much secure since you don't have to deal with passwords at all.
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?
After user being logged in with Google OAuth - is it possible to check if later user get logged out from Google?
Scenario:
User logged in in Google
User logged in on mysite.com using Google OAuth, and login state stored in session for 1 year.
User logged out from Google, but forgot to log out from mysite.com
After one week someone stoled user's laptop. Thief won't be able to use Google but will be able to re-use logged in user session on mysite.com
I wonder what are the ways to prevent such situation?
I don't want to put this burden on user - log out him from mysite.com and ask to log in again every day.
Would like instead use something automatic like:
When you logged in with Google OAuth you get some sort of ID
Every day you validate that that original session is still active, by calling something like
google.com/api/is-original-session-still-active?id=ID
Note: I suspect that you have your terminology incorrect i suspect you are using Openid connect and not OAuth2 to sign-in your users. However i will answer this question based upon Oauth2 as that's what you say you are using.
Oauth2
Oauth2 is used to grant an application access to a users data. When using an oauth2 token you are acting on behalf of the user. There is in fact no user interaction when using Oauth2 tokens.
If a user consents to your application accessing their data you will get an access token and a refresh token. Access tokens are good for an hour. Refresh tokens are long lived and will give you access to a users data for as long as the user doesnt remove your consent and that you use it at least every six months.
As Oauth2 is without user interaction there is no way to use it to see if a user is logged into their account. There is actually no Google api that would give you this information. This would IMO be considered privet user information and not something that google should be sharing with third party applications.
Suggestions
You may want to consider some changes to your application.
implement logout everywhere. If the user changes their password then all of the devices they have logged in should automatically need to be re-authenticated.
Your sessions should be good for only a week or two and you should enable sliding.
Tell your users to remove the consent of your application to their data this will also force them to have to relogin.
Specifically to know about user account security events that could impact users of your app if your app is using Sign In With Google, consider registering your app to receive events for Cross Account Protection.
Currently using the Provisioning API that is being depreciated April 20.
This is the current flow:
user (University Alumni) gets to our site http://alumni.columbia.edu/email
they click on Create My Account
they authenticate through our university WIND system using what we call their UNI
they land on a page mentioning that an email account UNI#caa.columbia.edu is ready to be created. They can pick an alias to UNI. They also need to enter a password to use the Chat and POP-mail features of Gmail.
they confirm the creation of the account. At this point the API is being called using https://www.google.com/a/feeds/, some data (email address, name, id) being saved in our database.
To log in, they come through our site, click on the login button, this will use the SSO and they get logged in.
Based on the flow above, do I need to use OAuth2.0?
Yes, you will need to authenticate with OAuth using the Installed Applications approach to do this. Instead of step 5 the way you currently have it, you'll need to call the API from a process on your server with an account that has (limited) admin credentials that can create the account with the Directory API. To do this, you'll need to persist the OAuth token information that the account will use to connect, and handle the code to refresh the token when it has expired.
The first time you run your code you'll need to manually authenticate that account to get your application the appropriate permissions so that they can be stored.
If you're hoping to not go too crazy with handling the authentication side of things and you're using .Net, I'd recommend checking out my project gShell that acts as a wrapper for the authentication and handles the token storing and refreshing for you. It's still a young project but it should fit your needs. Alternately, feel free to browse the code for an example on what to do.
If you plan on using Python, check out Google Apps Manager by jay0lee which is also a wonderful resource.
I have a Google Marketplace app that is currently using OpenID for federated login.
When an admin installs the application to the domain users are able to login via a site.com/login/domain.com link.
Currently when a user uses this link they are being asked to consent once again for "Know who you are on Google" scope. I understand that this is something to do with my OpenID realm not matching. The problem is I cannot find where to edit that realm in the new console. My research shows that OpenID has been abandoned for OAuth2 authentication. Please correct me if I am wrong.
Is there a good example anywhere that shows how to authenticate a user that an admin has already granted scopes for on the domain so that they do not get asked to consent again? I've looked up and seen documentation to make a call to https://accounts.google.com/o/oauth2/auth but I'm unaware of how to actually skip the user consent since the admin already authorized the scopes domain-wide.
Using C# but I'm open to any example as I'm sure I can figure out how to get it back into C#.
If you read this post on the google groups, then it seems it is intentionally :
This is an intentional change to more precisely communicate to users
the set of permissions that is being granted. Through knowledge of the
user's email address it is possible, via indirect means, to locate the
user's profile address. In the interest of more accurate disclosure,
thus, we are prompting users to approve such disclosure.
The new tokens issued include permissions to obtain public profile
information, in accordance with the modified text. You can use
https://developers.google.com/accounts/docs/OAuth2Login#userinfocall
to obtain the subset of user's profile information that is publicly
linked from the user's profile. The user's profile Id, which is always
public in that endpoint, is also a more reliable identifier for the
user (as email addresses can be changed on accounts). We recommend
that you store the user's profile id to ensure that email changes
don't cause account confusion.
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.