How can we check to see if 2-factor authentication is enabled for all users, and if not, how can it be enabled for all users?
Since recently there are 2 new fields isEnforcedIn2Sv, isEnrolledIn2Sv (both read-only) returned in the Directory API users.list() / get().
This one should be more accurate due to the big delay in UserUsageReport.
To check programmatically: The is_2sv_enrolled property of a user account's UserUsageReport will be true if the user has 2FA turned on.
To turn on for a user: You CANNOT turn it on programmatically for a user. A user needs to do this themselves.
Best practice for a large domain is to turn on Enforcement for 2-Step Verification. This can be done org unit by org unit and on a timeline with a deadline (that you can move) and allows exception groups. Users will gradually be provoked to enroll with interstitial prompt flows during login.
Related
I have an application and I use Cognito + Identity provider to use google accounts as my users. In Cognito, I have several groups, and in my application itself admin users can add users to groups, remove them from groups, and so on. The thing is, for these changes in the user to be reflected, the affected user needs to logout and in again in the application.
Having a new token fetched on every page load/request does not seem like a good practice. Therefore, I was looking for a Cognito function that would allow me to log a certain user from all it's active sessions. I looked for functions such as logout and revoke, but they require that I have the affected user's access token - which I obviously don't. After that I started playing around with other functions that could have the same effect, such as AdminForgetDevice - I thought that by forgetting a device maybe Cognito would log you out, but that is just used for 2FA, which my application doesn't support.
Seems to me a pretty basic thing what I'm trying to do, and kind of impossible to think that Cognito doesn't support it. Am I asking the wrong question? Is there an endpoint to accomplish this, or a different token-retrieval approach that I should use? I just want to make sure that if a user's groups were changed, those changes reflect immediately. My approach right now is forcing all that user's sessions to end.
I reached out to AWS support asking about this, and their official answer is that Cognito has no action to end all sessions of a specific user immediately. But I came to a solution on my own. You have two options:
1. User global signout and wait 1 hour until the user session is expired.
Not a fan of this solution. If you removed access from a user, makes no sense that the user can still use their old permissions for an hour.
2. Make your interface aware that the user should be logged out and use the logout function
This is the approach I'm going with. The moment an administrator changes a user's permissions, I am creating a notification for that user. The interface, once the user accesses it, know that there have been changes to that user because of the notification. The interface, then, in possession of the user's accessToken, can simply call the logout function.
my Google Cloud Platform App is in Test mode in order to be later submitted to Google for approvation.
This App was proviously in production, so there are more that 100 accounts authenticated to the APP.
This means that I'm above the limit for 100 max users in Test mode and I cannot add new account i need to make some test.
I'm not able to find a way to list the currently authenticated users and remove them.
Anyone could help?
limit of 100 users reacher
There is no way to list the users who have authorized your application, there is also no way for you to remove them. You need to wait for verification of your application before you can add new users.
option one
If you have refresh tokens for the users you can try to revoke them and see if that grants you another additional users. However my research says this will not help as the 100 limit appears to be the number of users who have granted your application authorization not the number of users who currently are authorized by your application.
option two
You could also create new project and go though the verification process again, this time taking care not to gather have to many users before the verification process has been completed.
Our Google app uses a scope that's subject to Google's verification process outlined here: OAuth API verification FAQs.
We use two Google oauth apps: production and staging. Our production environment has been verified (after an extensive security review). Our staging environment has not been verified, and so we're subject to the 100-user cap outlined in "Exceptions to verification requirements" in OAuth API verification FAQs.
However, we need to be able create more than 100 accounts to test our "new user sign up" flow. After we use these test accounts, we no longer need them to have access. Currently, new accounts are seeing "Sign in with Google temporarily disabled for this app".
Is there a workaround for the 100 user cap in which we can remove access to test accounts that we're no longer using?
It is not possible to add more then 100 test users while your project is still in the testing phase. It is also not possible to remove a user once they have been added as a test user.
While publishing status is set to "Testing", only test users are able to access the app. Allowed user cap prior to app verification is 100, and is counted over the entire lifetime of the app.
This does not change even if your app is part of the Exceptions to verification requirements section you are still limited to 100 usrs
Note that your app will be subject to the unverified app screen and the 100-user cap will be in effect.
Unverified apps
As per this support doc you can try to request a quota increase with the following form.
I'm struggling with a the new OAuth verification process that Google has introduced. Earlier, my OAuth app was using sensitive scopes, and I made changes to ensure that the sensitive scopes are no longer required, and removed them from the OAuth consent screen configuration.
However, my OAuth consent screen is still being forced to go through the verification process (which is a black box and never seems to complete!)
I noticed the following user-cap being breached. Could the forced verification be because of this? How do I check which users are connected to my app, and also manually disconnect them? I have never bothered about this user-cap in the past, so it is quite possible that a number of these are internal/test users when the app was under active development and was being tested in production. Btw, if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap?
Possibly related to How can I confirm the user limit of my google cloud/API? -- but that doesn't answer this question in detail.
I noticed the following user-cap being breached. Could the forced verification be because of this?
probably but only google can really anwser that
How do I check which users are connected to my app, and also manually disconnect them?
You cant there is no way for you to know what users where connected to your app and disconnect them unless you have saved a refresh token for these users if you have then you could remove them using the revoke command.
However this is no guarantee that the number google is displaying is going to change as it could be just a running total of users who have consented to your application in the past and not the ones who have currently consented. There is no way of know ing this as google hasnt told use.
if app simply deletes a user's refreshToken from the DB, and the user is forced to re-connect, will that count as +2 or +1 while calculating users against this cap
This may be true but that doesn't mean that the user has revoked your access to their application though their account. The only way to remove access is for the user to remove it in their account or for you to use the revoke endpoint to revoke them by force. Your application not having a refresh token doesn't mean that the user hasn't granted your application access.
Long story short your going to have to go though the verification process and wait for google to remove it when they see that you are no longer using the scopes that would require it.
Update: I have pinged someone on the team to see if this is working as intended or if it could be a bug. I will update this when i know more.
I've inherited an app at my company (ReactJS/Django), and they've asked me to implement multi-factor authentication. I've got it wired up with django-mfa, and the authentication works great. Now, they've requested that if a user logs in with MFA, they will not be asked for MFA again on THAT device for 30 days.
At first, I thought no problem. You can do it with a cookie or whatever as you would any persistent session, and instead of using that to keep the user logged in, you can use it to determine whether or not to ask for MFA verification.
The obvious oversight I made in my haste is that theoretically you could have multiple users logged in to that same device. User A could log in with MFA. If you store a cookie with session information that allows User A to skip MFA, what happens when User B logs in?
I don't really know any obvious way around this. Is there a straight-forward or conventional way to manage multiple user sessions in a browser, or an alternative approach to this problem I'm missing?