Originally, I believe the OAuth consent screen would allow the user to uncheck certain scopes they didn't want the requesting app to have access to (ie. the user could decide not to give the app permission to use phone_number). Google would then send user on their way to the App with whatever access scopes the user consented to. If the app absolutely required that permission then it would be the responsibility of the app to inform the user of this.
Now (I'm not sure when this changed) it seems the user is no longer given the option to deselect a requested scope. They can only allow it or be stuck on the consent screen.
Is this appropriate behavior according to the OAuth spec? To me it shouldn't be the responsibility of the resource owner to halt consent entirely due to the user denying a certain requested scope. This seems to be a Google bug, correct?
To be clear, I am working to make my app only request the scopes it absolutely requires. But I don't think that this change should be absolutely necessary.
Related
I just wanted to check my understanding here.
When I log into some applications e.g. Dropbox with my Google account, I get a consent dialog:
I can then revoke access in my Google account as I would expect.
However, when I sign into other apps e.g. SoundCloud, I don't get a consent dialog at all, it just takes me straight in. Neither does SoundCloud appear in my list of revocable apps in my Google account.
I am presuming that this is because SoundCloud does not require any information or rights with respect to my Google Account and therefore no consent is required. That is, all it requires is authentication, which does not require consent (presumably because entering your credentials is considered consent enough for this purpose).
I just wanted to confirm that I am correct in my assumptions.
You have found the answer to your question.
If you check Dropbox's login request, it contains a special scope value https://www.google.com/m8/feeds which stands for Mange your contacts (reference).
Dropbox scope parameter - scope=https://www.google.com/m8/feeds+email+profile
But if you check the same with SoundCloud, you only see profile specific scopes such as email profile openid
Soundcloud scope parameter - scope=email profile openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/plus.me
So yes, you get the consent page because of the special scope present in Dropbox authorization request. And consent page matches with scope value.
Further read this blog on default scopes and special scopes.
p.s - You can monitor these scope values with browser debugger. You must enable debugger for popups and navigations to see them. I used chrome to extract those values.
I am using Dropbox API v2. User of my app wants to logout from Dropbox with all his devices. I think this is equivalent to revoke all access tokens for my app.
I know how to revoke a known access token (and my app provides a logout which does this).
I also know that the user can unlink my app from his dropbox on the dropbox website (but this is a bit cumbersome).
For convenience, I would like to add a feature allowing him to do this from my app.
Another reason is, that processing of the callback-URL may fail. Then the generated access token remains valid, even if it is never used.
As Dropbox access tokens never expire, users might feel bad if there are unknown or unused access tokens flying around.
No, the Dropbox API doesn't offer a way to programmatically unlink/revoke all access tokens for an app. We'll consider this a feature request.
I used to redirect to logout page, which invalidate the token as well as "ask for permissions" for app on the next login ... it is not aesthetic, but worked.
if (this.isAuth()) {
this.authToken = '';
window.open('https://www.dropbox.com/logout', '_blank');
}
As part of our "off-boarding" process for employees leaving the company, as super admins we use the Google Apps Admin SDK Directory API to change the user's password so that they can no longer access their account. Then we log in to do a Google Takeout, reset passwords for their other accounts, etc.
However, we recently decided to enforce 2-Step Verification for all of our users. So now when we go to log in to their account, it sends a code to their phone.
Since 2-Step is enforced for their SubOrg, we can't even turn it off through the admin console. So all I can do now is to have the API move the user to a different SubOrg where the 2-Step enforcement setting is turned off, and then manually turn off 2-Step.
Is there any way to programmatically turn off 2-Step verification for an account?
I looked in the Google Apps Admin SDK Directory API Users:update documentation, but it doesn't seem to have anything to do with 2-Step.
The Reports API can find out the user's enrollment status, but it's read-only for reporting purposes.
What you are doing is the correct way to remove the 2-Step verification. As you mentioned if it is enforced under a Organization Unit, removing it would get against that rule and that's why you are not able to do it unless you move the user to another OU where this is not enforced.
I was not able to find some way to do this programmatically. However, you could Suspend the user. After that, the user won't be able to access to that account. The account will still be visible in your Admin Console and all the information in the different Google services will remain attached to that account until you finally delete the account.
While the user is suspended, as admin, you can use service account to impersonate that user. By doing so you can act as that user and edit permissions or transfer the ownership of the files contained in Drive to a different account so those files won't get lost.
I hope this helps.
The easiest way to do this is to create a Group for which 2FA is exempt (see here: https://support.google.com/a/answer/2370108). Then add the user to that group, then you can click "Disable 2FA" on the user page in the admin console. I'm assuming you can do the same through the API.
The only downside is that this means you'll have a group through which it is possible to exempt users from the 2FA enforcement option. So that's a risk you'll have to accept and a policy you have to carefully check.
I have a rails app that uses omniauth to enable user registration through facebook. My facebook app requests permission from the user to make posts to facebook on the user's behalf. My question is, is there a way for me to determine whether a user "skips" granting that permission during the authentication process (it doesn't seem possible for the user to actually reject the granting of this permission . . . they can only skip it)? I can't see anything in the request.env that is returned by the facebook callback.
Just as an aside, there seems to be all sorts of issues with fb-graph and granting posting permission. For example, even if a user "skips" granting this permission, when the user looks at his fb authorized apps, my app shows up indicating that the user has granted this permission even though fb blocks my app from making fb posts. Also, it seems impossible for a user to subsequently change his mind about allowing my app to post to fb: you can't even edit the application on fb to actually grant the permission.
Am I missing something about fb-graph???
You can check what permissions the user's granted to your app. All you have to do is issue an HTTP GET to /USER_ID/permissions with either a user access_token for this app, or an app access_token. This will return an object containing the permission names which the user has granted the application.
I'm using the Google Apps Provisioning API to synchronize user data with our internal database (MySQL). For every new user created through our site's backend, a corresponding user in created in the GoogApp system. Change is passwords are also synchronized accordingly.
I'm about to implement SSO, so that logins performed on our website automatically makes the user login into the google apps too.
My question is what happens IF the user happens to change his/her password using the Account > Settings in the googapps interface, instead of our own backend? Our system has no way of knowing about the change! Is there a way in Prov API or SSO with which I can turn off the password changing mechanism in googapp engine and let the user do it ONLY through our backend?
Anyone who's used / setup a similar system, please shed some light on it.
Thanks,
m^e
When you have SSO enabled in your Google Apps domain you have to provide a "change password" URL, that way when the users tries to go "Setting"->"Change Password" they will be redirected to your custom URL and make the password change in your backend.