Setting OAuth Security Policies that Secure Access for Your Specific Needs

OAuth 2.0 is a flexible framework for securing application access to protected resources through Application Programming Interfaces (APIs). OAuth allows you to decouple clients and resources from the business processes and policy decisions used to authorize access. It’s truly a framework, though, which means that it gives you a structure, but you ultimately must make the decisions about how to authorize access. 

To do this, you will establish security policies during deployment. But how do you know what policies to set? Understanding your specific threats and how they might impact your organization is a good place to start. From there, you can establish policies designed to provide the specific protection you need. 

Read on to gain a better understanding of threat modeling, how token policies work and things to consider to ensure you implement appropriate access policies for your environment.

Threat modeling provides a process to understand, communicate and reason about the potential threats to your systems. By first identifying all of the threats, you can begin to prioritize and address those that are most critical. Furthermore, by evaluating the system from an adversary’s point of view, threat modeling helps you identify vulnerabilities that might not be apparent otherwise so you can mitigate them before they pose a real problem.

While threat modeling is a natural first step in securing your enterprise, it’s a relatively rare organizational practice. You don’t need to undertake a full-scale formal effort to benefit from threat modeling, though. When you stay current on the most common threat models, you’ll likely see similarities between them and your own threat landscape. This knowledge alone can help you identify and mitigate potential threats to your own systems.

To get the latest information, you can consult the OAuth Security Best Current Practices. This document (in working group last call at the writing of this blog) provides the latest information about new types of attacks, how to accommodate attacks and implementation difficulties in production environments, and how to address the higher security requirements of financial services, healthcare and government verticals. 

While not explicitly covered in the Security BCP, you’ll also want to consider potential threats to your authentication procedures when evaluating your own threat model. Because of the centralization of responsibility, compromises to the authorization service will compromise all resources which trust in it.

Once you’ve identified your top security threats, you can begin to identify the policies best suited to protecting your systems. But first, you’ll want to understand how tokens work.

OAuth access tokens provide a level of abstraction between the various entities involved in a transaction so each is isolated from the responsibilities of the others and of the overall system. For example, a client acquiring tokens from an authorization server (AS) for a user typically leverages the user’s browser for any user interaction. This isolates the client from the authorization server’s processes for user authentication and consent. 

Also, when communicating with protected resources, a client applies tokens without necessarily knowing the underlying data or security policies those tokens represent. Similarly, a protected resource can validate that a request from a client was authorized by the resource owner, without knowledge or participation in the process the client used to get the token from the AS. 

While the business policy and processes and around what is required for authorization are defined by the AS, not the OAuth spec, the OAuth spec does define three places where an AS can interject its policy:

1. Before a token is granted, the AS can interact with the user via the user agent/browser for authentication and consent.
2. When using refresh tokens, the AS can use each refresh as a chance to evaluate policy. This could result in a change to the contents of a structured token such as a JWT, for example, or a decision to no longer allow the refresh token to be used before it has reached a time-based expiration.
3. When using non-structured access tokens (or a format that’s otherwise opaque to the resources), token introspection allows for policy to be evaluated on each use. Different protected resources can see different information, and token revocation can take place immediately.

Issuance, refresh and access can be thought of as a continuum. On the far left, token issuance has the most visibility to the user agent and the ability to interact with the user for authentication and consent. On the far right, structured access tokens act as a cache of a past policy decisions and enable performance at the cost of potentially stale information. Refresh tokens are in the middle, able to make policy decisions but not able to necessarily interact with the user.

Policy decisions may also lead to a cascading escalation of token requests from the client perspective. A short-lived access token will eventually require a client to fetch a new access token via a refresh grant. At this point, the evaluation of policy by the AS might require interaction with the user, so it fails to refresh. This causes the client—which still needs an access token to interact with protected resources—to request a new token, presenting the user to the AS via the user agent or browser.

In some environments, there may be a fourth place where the AS can interject policy. In this case, a client may first request an access token and redirect the user, while requesting the AS fail rather than presenting UI to the user. This allows the client to better control the user experience when the user must re-authenticate to continue interaction with the protected resource.

Online vs. Offline OpenID Connect Token Policy

While the implementation of token policies is outside the realm of OAuth, OpenID Connect (OIDC) does provide two different types of token policy: online and offline. An offline token policy is one where access continues beyond when the user is present beyond the current authentication session for the user. For example, I might grant access to a meeting service to read and modify my calendar. The expectation is that I’m granting access in order to increase the capabilities of the application even when I’m not present, such as exposing my free and busy status during scheduling. 

An online token policy, on the other hand, will enable access only when I am present and will terminate access once I’m no longer authenticated. An example might be a browser app written in Javascript. The user might not understand the distinction between the AS and client app because they are presented in the same browser. If the user isn’t interacting with the app, there is often no reason for a browser-based app to maintain access.

Many AS implementations do not enable refresh token policies based on whether the user is still authenticated. For this reason, some people equate offline access to mean that a refresh token is issued, while online access indicates no refresh tokens are issued. But this is only the case in certain AS implementations, and both of these statements can be false depending upon the specific AS implementation and policy.

As you begin to consider what sort of policies are appropriate for your OAuth deployment, you can seek guidance from the work of existing standards groups. The National Institute for Standards and Technology (NIST) provides guidance around authentication, while the IETF OAuth working group provides a set of security best practices. You will also want to determine how to appropriately manage user consent, and to tightly control access to your resources via OAuth scopes.

Using the NIST Guidelines

NIST Special Publication 800-63 provides recommendations on types of authentication processes, including choices of authenticators, that may be used at various Authenticator Assurance Levels (AALs). The guideline specifies three different AALs:

Authenticator Assurance Level 1 (AAL1): Requires either single-factor or multi-factor authentication (MFA) using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.

Authenticator Assurance Level 2 (AAL2): Requires proof of possession and control of two different authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required

Authenticator Assurance Level 3 (AAL3): Requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. Claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

The following diagram illustrates how the level of authentication is determined based on the criticality and potential consequences of the threat.

Image Source: NIST Special Publication 800-63-3, Digital Identity Guidelines, June 2017.

While NIST can provide guidance, it does have limitations. It’s meant to provide a uniform standard for authentication levels across government agencies, but it doesn’t discuss the threat model used to make its policies nor the reasons for choosing the particular mitigations. 

For example, NIST doesn’t explain what threat is mitigated by the inactivity timeout requirements for AAL2 and AAL3. (The gap in activity is actually a signal of a potential change in users in cases such as an unlocked terminal or phone forgotten in a public place.) It also doesn’t discuss other potential mitigations, such as leveraging screen lock and password complexity requirements of the device rather than measuring browser activity.

If you’re designing your own authentication policies, you’ll want to focus on the threats and mitigations rather than a combination of authentication factors. For example, requirements for password complexity, rotation, and uniqueness mitigate the same threats of password theft and replay that are solved by multi-factor authentication. MFA may allow the use of simpler passwords that can be used for a longer period of time. Taking the big picture into account allows for risks to be mitigated while limiting impact to user experience.

Consulting the OAuth Security BCP

Mentioned earlier, the OAuth Security BCP also provides an excellent list of threats and mitigations. When possible, it is recommended to adopt or migrate to the recommendations of this document. 

However, it’s also important to take criticality and consequence into account when planning how to adopt or migrate to the practices in the BCP. For example, while the document makes a solid case for not using the implicit grant, migration of existing applications may not be prioritized if those clients have highly restricted access to data.

There are several new and emerging standards around OAuth to support the recommendations of this BCP, such as the Mutual TLS RFC. In some cases, adopting recommendations may be simpler if the AS supports these emerging standards.

Properly managing user consent

Every time a token is issued, proof of user consent should be required. However, this proof could come from multiple places:

• Presentation/acceptance by the user inline in the authentication/authorization experience
• Prior consent for this particular client
• Implicit consent by the client being a ‘first party’ client, under the same terms of service and privacy policy as the resources it is interacting with
• Consent by virtue of prior agreement, such as employees accessing internal resources

Just as an organization may expire tokens periodically to force user interaction, they may choose to expire consent periodically so that the user self-governs third-party service access. Privacy regulations such as GDPR may come into play as well, placing requirements on the processes of acquiring, presenting, and revocation of consent to and by the user. In any case, revocation of consent should also include revocation of any active tokens granted to clients under that consent.

Restricting access to scopes

Tightly controlling access to OAuth scopes, such that clients only have access to the scopes they need, can be an effective tool at mitigating threats to your organization. Depending on the capabilities of the AS, certain scopes may require a higher level of authentication assurance when requested, as well as cause tokens to be issued under a more restrictive policy.

Likewise, organizations may decide certain scopes (such as administrative access or access to confidential information) may require additional vetting of client software. In the most extreme cases, certain clients such as in-browser applications and native applications may not meet your requirements for certain scopes.

Given the virtually limitless possibilities, you may understandably want additional guidance when setting appropriate token policies for your organization. The following rough guidelines can provide a starting point:

1. Access tokens often exist as a short-term representation (or handle) to the authorization grant. If possible, structured tokens (such as JWTs) should be used to allow the individual protected resources to validate the access token without contacting the AS. The lifetime of the access token is a trade-off between the amount of time that a “stale” access token is allowable within the system. Generally, you don’t want to set this value below five minutes as this can cause issues like clock drift between components to become a significant issue.
   
   
2. If an access token can’t be allowed to go stale, then tokens should be opaque to the protected resources and validated by hitting a token introspection endpoint. This centralization of access can significantly impact the overall performance of the system, however.
   
   
3. Expiring refresh tokens in an “online” token policy is an effective way to give the AS control back to potentially re-authenticate the user, so a refresh token policy in this scenario might be statically set to a value equal to or smaller than the re-authentication timeout.
   
   
4. For environments without refresh tokens, a client may request new access tokens first without prompting (aka “prompt=none”, as specified by OpenID Connect.) This lets a client reduce user interruption.
   
   
5. For “offline” token policies where a back-end system may have delegated authorization to protected resources for an extended/unbounded period of time, it is advisable to either set the refresh token timeout to a period where you plan to prompt the user for re-approve consent or to use token revocation to allow business processes to terminate refresh tokens.

The security community is continuing to invest in OAuth and OpenID Connect through security reviews, new standards and new capabilities in implementations. To ensure your policies take advantage of these ongoing improvements, you should periodically review changes made by the standards body and changes available via new software vendors. The standards bodies may have provided new security considerations, as well as new techniques to mitigate them since your last policy review. Furthermore, implementations of client libraries, resource server tools and authorization servers may gain new capabilities, allowing for more sophisticated usage to better mitigate your environment’s security concerns.

To learn more about OAuth 2.0, check out The Essential OAuth Primer.