Corporate Assets and Users

Background

Our First Sample Application focused on some technical mechanics to introduce the reader to OAuth 2.0 technologies.

About this Post

Most online examples are all about Personal usage, whereas security often works differently in the Corporate World. It is worth being clear about potential differences, to clarify how you will use the technology.

My Company Background

I worked for Dealogic, who are a software provider with a Suite of Mature Products used by multiple Investment Banks:

Our products had to provide characteristics of both Internet Web Apps and also those of Corporate Apps:

  • Modern, Easy to Use, Globally Fast UIs for End Users
  • Corporate Assets protected via Complex Investment Banking Rules
  • Bank Security Reviews and PEN Tests were run on our software

My opinions are of course shaped by my background and your Corporate Assets may be used very differently. However, I think some of the points I raise are likely to be common to many companies.

APIs and Authorization Rules

We have used Token Introspection to validate API calls, but of course this is just a first line of defence, and the real security is in your API logic. In some sectors you may need to enforce rules such as these:

  • User Bob has Write Access to the 7 Customer Accounts he covers
  • User Bob has View Access to Other Accounts for his own Branch
  • User Bob has No Access to Accounts for Other Branches

Simple concepts such as User Roles or OAuth Scopes are often insufficient to work out which data a user has access to:

OAuth 2.0 and Delegation

OAuth 2.0 is often described as a delegation protocol. After Login there is an Approval Screen where the End User Grants an Application Access to Personal Assets for a while:

In the Corporate world the delegation setup is often done when an Administrator Grants a User Access to Corporate Assets.

In some Corporate Setups it can therefore make sense to Bypass the OAuth User Consent Screen, if the delegation is administrator configured.

User Onboarding

When dealing with Personal Assets it is common that Users can Register Themselves online and quickly start using the application.

However, when dealing with Corporate Assets, New Users often need to be Provisioned by an Administrator, and this may include actions such as assigning the user one or more Product Roles.

User Management UIs

We can use Okta to simulate an Administrator action to Create a New User – though large companies use automated solutions to provision users.

Note that it may not always be possible to fully configure a user in one place:

  • A New User may first need to be created centrally to Enable Login
  • The New User may need to be granted Product Specific Permissions

User Sign In Differences

If an End User is managing their personal assets they are usually happy to use the Application’s Default Sign In.

For software that manages Corporate Assets however, companies are much more likely to want to integrate their Corporate Security Policy:

When a user leaves the organization they are then automatically removed from LDAP and no longer have permissions to the Corporate Assets.

Corporate Apps and Social Logins?

In Corporate Apps, users will typically never be allowed to sign in with their Personal Facebook Account (though you never know).

Some OAuth related cyber attacks are more likely when Social Logins are used, and the User Consent Form can help secure your system by informing the user which application they are interacting with.

APIs and Access Token Lifetime

Access Tokens that last for a month are unlikely to be used with Corporate Assets, and a short value such as 30 minutes is preferred.

In Okta we will configure this under API / Authorization Servers / Default / Access Policies / Default Policy Rule:

This ensures that an attacker who somehow steals an Access Token cannot use it against your company APIs for long.

APIs and Audience Restriction

Corporate APIs can use the Client Id in the token as part of their authorization, to restrict access to only trusted applications:

This can help mitigate token substitution attacks, where an access token for a malicious application is copied into your application’s callback URL:

APIs and Access Token Privileges

Running with Least Privilege is generally recommended in software, so if possible use low privilege tokens:

  • Issue Access Tokens to your SPA that contain Low Privilege OAuth Scopes, even if the user in the token has High Privilege

This ensures that an attacker who steals an access token with only a ‘read’ scope may be able to read data but will not be able to change it.

Are your Assets Secure?

Obviously this blog cannot make your OAuth based applications secure, and any company needs to think through its own security.

The OAuth 2.0 Threat Model is worth reading to understand known OAuth risks and mitigations. Section 4.4.2 is focused on the Implicit Flow.

Where Are We?

Hopefully this post gets you thinking about how OAuth concepts will translate to your Corporate Assets, and how you will control User Access.

Next Steps

  • Next we will cover some thoughts on Managing User Data for your software products when migrating to an OAuth Architecture
  • Return to the Index Page to see topics in a logical sequence.