Custom OAuth 2.0 scope usage examples in API Gateway

These examples show how to configure and use custom OAuth 2.0 scopes in API Gateway for non-Infor API access control scenarios.

Custom OAuth 2.0 scopes support multiple access control models for non-Infor API suites. These examples show common implementation patterns for authorized applications, API suites, and scope enforcement.

Prerequisites and setup

Prerequisites for all examples

Before scope enforcement takes effect, enable Enable Scopes per authorized app under Configuration > OAuth 2.0 Settings and enable the Enforce Scopes toggle on each authorized application.

These configuration steps apply to all example scenarios.

Restricting and isolating application access

Example 1: Restricting a partner application to a single API

Scenario: Your organization hosts a third-party shipping API as a non-Infor API suite called ShipmentTracking. A partner application, PartnerLogisticsApp, must only call this API suite.

Solution:

  1. Create a custom scope named shipment-tracking-access.
  2. Associate shipment-tracking-access with the ShipmentTracking API suite.
  3. Enable Scopes per authorized app under Configuration > OAuth 2.0 Settings.
  4. Assign the shipment-tracking-access scope to PartnerLogisticsApp.
  5. Enable Enforce Scopes on PartnerLogisticsApp.

Result: PartnerLogisticsApp receives the shipment-tracking-access scope in its token. The gateway allows calls to ShipmentTracking and rejects calls to other scope-protected suites.

Example 2: Isolating access between two applications

Scenario: Two non-Infor API suites exist: InventoryService and PricingService. WarehouseApp must only access InventoryService, and SalesPortal must only access PricingService.

Solution:

  1. Create two custom scopes: inventory-access and pricing-access.
  2. Associate inventory-access with InventoryService and pricing-access with PricingService.
  3. Assign inventory-access to WarehouseApp and pricing-access to SalesPortal.

Result: Each application's token contains only the scope for its assigned suite. Cross-access is blocked.

Multi-suite and shared-scope access models

Example 3: One application accessing multiple non-Infor API suites

Scenario: Three non-Infor API suites form an order management system: OrderEntry, OrderFulfillment, and OrderReturns.

Solution:

  1. Create three custom scopes: payment-access, crm-access, and notification-access.
  2. Associate each scope with its respective API suite.
  3. Assign all three scopes to IntegrationHub.

Result: IntegrationHub receives all three scopes and can call all three suites. Revoking access to one API requires removing only that scope.

Example 4: Shared scope across related API suites

Scenario: Three non-Infor API suites form an order management system: OrderEntry, OrderFulfillment, and OrderReturns. Applications that access one suite typically require access to all three suites.

Solution:

  1. Create a single scope named order-management.
  2. Associate order-management with all three suites.
  3. Assign order-management to each application that requires access.

Result: A single scope grants access to all three related suites, which simplifies administration.

Scope rollout and mixed-suite access

Example 5: Gradual scope rollout

Scenario: You want to introduce custom scopes across the tenant, but existing applications are not yet updated with scopes.

Solution:

  1. Enable Scopes per authorized app under Configuration > OAuth 2.0 Settings.
  2. Create custom scopes and associate them with target API suites.
  3. Start with one application. Assign scopes and enable Enforce Scopes on that application.
  4. Test the application.
  5. Gradually enable Enforce Scopes on additional applications after assigning scopes.

Result: Applications without Enforce Scopes enabled continue to work without scope validation. Only applications with the toggle enabled are subject to scope validation.

When Enforce Scopes is disabled on an application, the gateway does not enforce scopes for that application's tokens. After you enable the toggle, the application must include the required scopes in every token request.

Example 6: Application calling both Infor and non-Infor API suites

Scenario: UnifiedDashboard calls an Infor API suite, InforERP, and a non-Infor API suite, ExternalAnalytics.

Solution:

  1. Ensure that InforERP has its standard Infor scopes enabled through Registry.
  2. Create a custom scope named analytics-access and associate it with ExternalAnalytics.
  3. Assign the Infor scopes and analytics-access to UnifiedDashboard.
  4. Enable Enforce Scopes on UnifiedDashboard.

Result: The token contains both Infor scopes and the custom scope. The gateway validates each scope type independently for each API suite.