Since BIM360 allows users to disable 2-factor authentication for themselves one of our clients requires a way to prevent access to files / monitor if users turn this feature off.
For forge-applications managed by me I got this covered through following endpoint :
https://forge.autodesk.com/en/docs/oauth/v2/reference/http/users-#me-GET/
Problem is, users without 2-fa can then still access the files if they go directly through the BIM 360 docs webapp (docs.b360.autodesk.com). Is there a way to restrict acces on the bim360docs platform based solely on 2-fa or a way to use the users-#me endpoint in a way that allows me to monitor a project when those users aren't logging in on my applications?
Sorry, this information is only accessible for the current user (who authorized the 3 legged access token).
Related
We are using G Suite API with our Micro service for document editing, and we have a different data center and also different db. now once user comes to my application and trying to open document first time then google give consent screen based on that i can get refresh token and access token and i store into one data center.
But problem is that if user comes from another instance which use different data center with different db and user trying to open document with old credentials then google doesn't give any consent screen so i am not getting user's refresh token.
1) So is there any way to get refresh token without using consent screen?
2) Is there any way to identify if user comes from different sub domain then i need to provide consent screen for that?
It might be possible to use the prompt=consent option to force a re-prompt for auth, even though the user has already authorized your app.
See https://developers.google.com/identity/protocols/OAuth2WebServer#creatingclient
You can identify the user's domain using the hd parameter [1] and you can request a refresh token without the consent screen after the domain admin has configured domain wide delegation by installing your application from the GSuite Marketplace [2].
[1] https://developers.google.com/identity/protocols/OpenIDConnect#hd-param
[2] https://support.google.com/a/answer/172482?hl=en
When you request an OAuth Flow (access_type=offline`), a Refresh Token is returned to your application. This only happens once (obtaining a Refresh Token). Your application is expected to save the Refresh Token for future needs.
In your use case, one of your systems completed the authentication and the user has moved to a different system. You will need to reauthenticate with prompt=consent, access_type=offline. You will not get another Refresh Token without reauthenticating.
I spent a lot of time on this issue last November. Here is a link which has lots of details on this problem.
Any application can only have one valid refresh token for a user. You can request for a new refresh token using the prompt=true&access_type=offline on the request as said by #John. But every time the previous one will become invalid.
Based on you comments on the other answers, I'm assuming creating a new micro service that returns the token to the one being used is not a possibility (that would be my recommendation)
You asked "to identify if user comes from different sub domain"...
If those applications are for end users of gmail.com accounts, you can treat them as different applications and configure different projects on the developer console.
It will be a bit of a pain when enabling new APIs, I would recommend doing that from a script that replicates to all application needed.
If your end users are from companies using GSuite, you can have your app installed as domain-wide application (either manually or from GSuite Marketplace). In that case you can use just client side authentication to get an id_token, send the token to the server and use a service account to impersonate the user in any given service without worrying about any token from them.
I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.
We have a user who gave consent for our Cloud Project to read their Fit data through the Android app. We now want user's coach to access their Fit data through a web UI associated with our Cloud Project. Is this possible, and if so, what is the right way to do it?
Can cross-client identity be used? https://developers.google.com/identity/protocols/CrossClientAuth
I was trying to replace "me" with "user#gmail.com" in the REST endpoint but it doesn't work:
https://www.googleapis.com/fitness/v1/users/me/... ->
https://www.googleapis.com/fitness/v1/users/user#gmail.com/...
Thanks!
There is a mechanism for Android apps to obtain offline access for web back-ends highlighted in the CrossClientAuth guide from your question. With offline access, you can theoretically serve or store that data in any way that the user has consented to. Any access controls of that data to another person is something that you'd have to handle on your own.
I have a web application that we are building. We need a text editor to allow for our registered users to create and or edit documents. We want the documents to be used within our app, but would like to use the Google drive interface to create/edit/upload docs. What I am concerned about is the OAuth2 process. I would like for our web app to be the authenticator, and allow our users access to our files/folders that are under our account rather than theirs. Can we do this? All of our users are authenticated by our application already, and we do not want them to have to use their personal credentials to access files used by our application.
According to Google's documentation:
Each Gmail account intended and designed for use by an individual
user. If you have multiple users frequently accessing the same account
from various locations, you may reach a Gmail threshold and your
account will be temporarily locked down.
Anecdotal evidence confirms this: a worker at a school reported a 403 error possibly caused by too many people logging into the same account at the same time.
When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.