1Password SaaS Manager assigns an "access risk" level to any application in your inventory that accounts are accessing via single-sign-on (SSO) with OpenID Connect. A common example of OpenID Connect SSO is a "Sign in with Google" option, which allows team members to log in to an app or website with their existing Google Workspace account.
Access risk is just one way of looking at the risk in your SaaS inventory and can help you make decisions about the apps that SaaS Manager is discovering. For example, an app that is predominantly for home use and that has high access risk might be something you want to address.
You can find the access risk score in the Applications view, in the Permissions risk report (available from the Reports list), and on individual application profiles.
"Sign in with Google" (or Microsoft) isn't necessarily a bad thing for staff to use on non-business related apps. The app will know their work email address, but it does mean that the account isn't potentially reusing a password. The risk is that accounts can inadvertently, or carelessly, grant additional access to Google Workspace resources which contain company information.
How SaaS Manager defines risk
SaaS Manager access risk grading is based on OAuth Scopes. When an individual logs in to an application using OpenID Connect SSO, they are usually prompted to grant the application various permissions. These permissions are granted via OAuth scopes.
Google and Microsoft support hundreds of OAuth Scopes, ranging from basic, low-risk permissions that grant the account access to an app, through to permissions that give a third party app complete access to a team member's email account or cloud file storage.
You can find a much more detailed review of the technology behind these OAuth Scopes in this blog post.
Google’s sensitive OAuth Scope list
Google flags 46 OAuth Scopes as being sensitive and requires vendors of apps using these scopes to undergo additional verification when registering for Google Sign-in. Our "high risk" category is based on these sensitive scopes; any app using any one of these scopes is categorized as high risk.
Occasionally an app might provide multiple routes of access via OAuth, such as a simple login alongside an add-on that integrates data from a Google Sheet. One route of access may be categorized as low risk, while the other is high risk. In this situation, if a single account has authenticated with the high risk scopes then SaaS Manager categorizes the whole app as high risk.
There isn't a direct equivalent for Microsoft's OAuth scopes. To grade access risk for Azure AD-based OAuth we've mapped Google's sensitive scopes list to Microsoft's.
Inherent vs contextual risk
The high risk category addresses the inherent risk that comes with accounts granting broad permissions to third party apps. Access risk doesn't address the contextual risk that comes from account behavior within an application, such as an account uploading PII to an unmanaged app. Irrespective of the risk categorization for that app, this account behavior represents risk by virtue of the fact that an account is making decisions about which third parties are holding your organization’s sensitive data.
Why don't I see an Access Risk for an application?
SaaS Manager detects applications from multiple different sources, including:
- Single-sign-on to applications through your Identity Provider (e.g. Google, Okta, or Azure AD).
- Spend data from a finance or expense system.
- SaaS Manager Browser Extension.
- Manually entered applications.
Access risk only applies to applications detected from your Identity Provider, and only to a very specific form of SSO called 'OpenID Connect'. OpenID Connect is most commonly seen as 'Sign in with Google' buttons on some web applications, although it's also available on some apps for Microsoft 365.
If a team member is connecting to an application by selecting an icon in a 'My apps' dashboard, or logging in without using a 'Sign in with Google' button, then they're likely connecting using SAML2 Single Sign On which doesn't represent any access risk.
Finally, if someone did log in with OpenID Connect, but a very long time ago, then the so-called "access token" that lets the application interact with your Identity Provider might have expired. Since this no longer represents an active risk, the access risk will not be shown for that account against an application.
Manage high-risk apps
We recommend that you review any non-business apps that are identified as high risk. From your App inventory, select the "Non-business" view and sort by "Access risk".
If you are concerned by the risk presented by an app, you can revoke individual accounts' OAuth tokens. This revokes the app's access to the team member's Google Workspace account. However, it does not prevent the account from re-granting those permissions if they log in to the app using OpenID Connect SSO again in future.
To prevent accounts from logging back in to an app with OpenID Connect SSO and re-granting OAuth scopes, you can block the app in Google Workspace.
Comments
0 comments
Please sign in to leave a comment.