What Does it Mean to Be a Modern App?

Originally published by Strata.

Written by Ben Robertson, Principal Solutions Architect, Strata Identity.

There’s a common thought that if an application speaks industry-leading identity standards, it automatically makes it modern. However, the requirements of apps today go beyond that. How the protocols are applied is just as important as having them in the first place.

An app can have SAML, OAuth, OIDC, or whatever the most up-to-date standard may be in front of it but still follow insufficient security practices. It could have a beautiful authentication experience that feels super slick, but authorizations don’t follow zero trust security practices.

If set up incorrectly, a standard loses its value to the app; in fact, the application really isn’t modern at all. So then, what does define a modern application (and what doesn’t), and why is it so important? I’ll explore this below and explain how delivering an authentication experience that looks great yet ensures user data remains secure and protected at all times is possible.

What a modern application is not

Before defining a modern app, let’s clarify what a modern app is not.

First, a modern app does not store usernames and passwords in any way. Anything that’s asking you for credentials on its way through the authentication process is not modern.

Second, an application is not modern if it just has single sign-on (SSO) with OAuth or OIDC to authenticate. Yes, that worked a decade ago, but the ways and means bad actors get in are much more sophisticated today, so the security demands are much more significant for any application now.

Third, a modern app is not an OIDC app that just uses all the most up-to-date recommendations in OIDC and then uses the best common practices. The best practices outlined by OIDC are a good start; it lets a user in the front door safely, but then what? That does not allow you to have a way to evaluate continuous access.

What is a modern application?

A modern app relies on fine-grained authorization in scopes and in claims of tokens to make authorization decisions. It does not do it within the application menu or an administration console. That could work for one app but would not be scalable when most organizations have hundreds, thousands, or even millions of applications (which most enterprises do).

App modernization is the process of updating the infrastructure, architecture or features of a legacy application to be able to move it to the cloud. An app needs to speak modern standards before adding things like MFA, passwordless and other tools to make the app more secure, agile, and efficient.

Continuous authentication

An application needs to be able to authenticate a user’s session continuously. It’s not enough to trust that the user is still who they say they are at login throughout that session.

Context or attributes about a user that can change. If a user’s context changes — such as shifting entitlements, moving geographical locations, or getting a new device — a mechanism to reevaluate their access needs to be in place and enforceable. Many applications that claim to be modern today don’t have that functionality.

An application consumes a token as soon as it gets it and gives the user a session of a set amount of time. A modern app has the ability to have continuous access visibility on how the context of that user’s access has changed.

Externalized controls

A modern app has to have externalized authorization controls. If an organization has hundreds of apps and they all manage their own fine-grained authorization, it gets unmanageable.

Instead, we need to use tightly managed scopes to determine what a user can do in the application based on known attributes about that user. That way, all AuthN and AuthZ processes can happen somewhere centralized and easy to manage, so they never have to be redone within the apps themselves.

Least privilege

One of the tenants of zero trust is least privilege. It assumes nothing, and no one should be trusted until proven otherwise, and then it should be continuously assessed for risk.

To have least privilege, you need to have very fine-grained authorization rules on each individual resource. An ideal application would very tightly rely on scopes within an OIDC token to determine access, but the different kinds of fine-grained authorization apps allow is usually limited. Properly configured applications should have every resource and action tied back to a specific token scope.

The significance of least privilege

Least privilege means allowing users the minimum access to resources to do their job properly. A big challenge today is IDPs and applications have statically defined roles; this doesn’t allow for fine-grained access. It’s too broad.

Externalizing fine-grain auth means relying on user attributes that live at the source of truth. These attributes should be used in policy-based decisions to determine who has access to what data and what information, and that’s fine-grain access.

It is necessary to be able to trust the scopes provided by the authorization server, an IDP, or another token, and those attributes should define what a user can see or touch. It takes the onus off of each application owner and puts it on to more of a centralized policy store, where it should be.

Static authorization

We need to be able to utilize all of the attributes or as many pieces of data as we need to make as strong an access decision as possible. Most access is built on static roles, making attribute-based policy difficult.

For example, if you’re onboarding a contractor to help with a specific project, that person will need access to the team’s project management tool. Editing the contractor’s user account and permitting access within the tool is not ideal. It’s a static role that would rely on the app owner to manually go in again when the contract or project ends to revoke access.

Dynamic authorization

On the other hand, dynamic access or just-in-time authorization is based on some source of record or data source. Relying on dynamic authorization means calling out to the source data at each login to see if the user has an active engagement with the organization and then grants or rejects access.

When the contract ends for the contractor from the above example on a set date, that user won’t have access to the app anymore. No one has to go into the app to revoke access manually.

How to ensure your apps are modern

Basic principles of modern applications are a good start to securing your apps: have OIDC, get rid of passwords, use OAuth, and have phishing-resistant MFA. But it’s not enough.

These three elements are necessary to ensure your apps are modern:

• Be able to trust entitlements. That means having real-time information.
• Have distributed fine-grain enforcement close to the applications.
• Ensure continuous access enforcement even after a session in an application has been granted and then every step along the way.

If you follow these practices, that means your applications are truly modern. It also means you have a scalable way to enforce security across all the applications in your organization.