Skip to content
Platform Strategy

OAuth2 Scopes in Trimble Identity: Current State and Future Plans

Author(s): Siva Soundarapandian, Trimble Distinguished Engineer

Last Reviewed: Jul 2024

Introduction

OAuth2 is an open standard for authentication and delegated authorization. Trimble Identity supports OAuth2. OAuth2 scopes specify the extent of access that the application is requesting from the user. By defining scopes, OAuth ensures that applications only receive the permissions they need, without exceeding the bounds of what users have approved, thereby enhancing security and privacy in the process of delegating access. There are a number of benefits to using OAuth2 scopes in Trimble Identity. These benefits include:

Improved security: Scopes help to improve security by limiting the access that applications have to protected resources.

Granular control: Scopes allow for granular control of access to protected resources. This means that applications can be granted only the permissions that they need.

User transparency: Scopes provide users with transparency into the permissions that applications are requesting. This helps users to make informed decisions about whether or not to grant those permissions.

This white paper delves into the current state of OAuth2 scopes within Trimble Identity, identifies its limitations, and outlines a forward-looking strategy to introduce granular, dynamic, and user-centric access control mechanisms.

Current State of OAuth2 Scopes in Trimble Identity

Scopes are significantly underutilized in Trimble Identity today. Some of the current challenges include:

Incomplete Scope validation: The system supports the definition of arbitrary scopes for applications, yet verification is limited to the initial scope level correlating with the application name.

Absence of explicit user consent: There is no explicit user consent or approval for OAuth authorization for 3rd party applications, making the flow out of step with industry best practices.

Plans for OAuth2 Scope Improvements

Trimble Identity is set to progressively enhance its scope mechanism through a series of iterative improvements over 2024 and 2025. Each phase is designed to build upon the previous one, ensuring a seamless evolution towards a more robust access management system.

Refined Scope Validation

The current practice of validating scopes based solely on a “scope prefix” of a known TID Application has been identified as insufficient. This allows clients to request any scope, even an unregistered one, for any resource server application within API Cloud. This undermines the trust in TID’s scope implementation, as resource servers have no reliable means to verify that a scope listed in a submitted JWT has undergone a rigorous validation process by the authorization server.

To address these concerns, the proposed iteration introduces a more stringent validation process. When scopes are requested by a client application (B) for accessing the resources of a resource server (A), each requested scope, S, undergoes a two-step validation.

  1. Firstly, if S is a scope registered by the resource server A (especially when A and B are the same entity), it is approved.

  2. Secondly, if S is a scope registered by resource server (A), and client application (B) is subscribed to resource server (A), then S is approved.

  3. Any scope that does not meet these criteria is denied.

This improved algorithm enhances the security and reliability of scope validation in Trimble Identity.

A third-party application is defined as any software application that is not provided by Trimble and not associated with the account or organization of the logged-in user. When a user logs in to a third-party application, it is required to obtain explicit consent. This process will empower users with control over how resource information is shared with third-party applications. A sample consent screen will look something like below:

Consent Screen

Achieving this involves:

Defining Granular Consent Scopes: Any protected application/API of Trimble Identity will be able to provide clear and precise consent scopes from API cloud to ensure users understand what they are consenting to. It is the responsibility of the API/application publisher to provide the scopes.

Providing Consent: Trimble Identity consent screen presents the specific scopes requested by the third-party application. The user must authorize these scopes for the application to access resources on their behalf.

Managing Consent: Users should be able to manage their consent through their profile page.

Individual user consent, while suitable for personal users, falls short in meeting the complex needs of enterprises. For users linked to a Business Account, consent management demands a more sophisticated approach, necessitating control at the Account level. We will provide the flexibility for the account administrators to oversee consent for all associated users or allow individual users to provide the consent.

When access to a third-party application is requested by any user within the Business Account, a specific workflow is initiated depending on the option chosen. The user provides the consent directly or the administrator manages these consent requests through the Account Experience interface, ensuring centralized control and streamlined management of third-party application access across the enterprise.

The coarse grained consent definitions (e.g., files-service:file.read) grant applications access to all of a user’s files, lacking the granularity for specific resource access (e.g., files-service:file.read.file1). The proposed mechanism will introduce Dynamic Scopes. These scopes, definable with wildcard characters, will facilitate flexible requests for authorization, targeting specific resources and actions.

The API/resource server can specify scopes using pattern or wildcard characters, structured as “<api-name>:<resource-type>.<action>:[*]”. This design enables a flexible and dynamic scope definition. When a client application seeks access on behalf of a user it can replace the wildcard with the specific resource identifier, tailoring the request to precise access needs.

For instance, a dynamic scope request can be “files-service:files.read.file1” where “file1” specifies the actual resource instance for which access is requested. It is up to the resource server to really validate that the user has access to the specified resource.

This allows for granular access control, with the client application specifying the exact resource and action required, thereby enhancing security and flexibility in access permissions.

Conclusion

The strategic overhaul of OAuth2 scopes in Trimble Identity represents a significant leap towards a more secure, flexible, and user-centric approach to access management. By addressing the current system’s limitations through granular, dynamic, and enterprise-level enhancements, Trimble Identity is set to provide an appropriate level of control and transparency to both individual users and organizational administrators. As we embark on this journey, we invite collaboration and feedback from the Trimble community.