Box Developer Blog
Published in

Box Developer Blog

OAuth 2.0 Custom Application Enablement

Today, we improved the custom application approval flow, allowing OAuth 2.0 custom applications to be enabled more efficiently.

When you create a custom app, it is treated as unpublished until it makes it into the App Gallery. By default, unpublished apps do not require enablement; however, if your Box Admin changes the enterprise settings for apps, you will have to request approval before using your app.

To make things easier, we automated this process. If your app requires approval, you will see the Enablement tab in the Developer Console. Click Review and Submit to pass the app details to you Box Admin via email.

New Enablement tab

Additionally, the app will appear under User Authentication Apps in the Custom App Manager section of the Admin Console, where a Box Admin can review and approve it.

User Authentication Apps

If you are interested in the Custom App Manager and its features, have a look at the article exploring more Custom Apps Manager updates. It will provide you with additional details on how Box handles authentication and authorization of custom apps.

We hope you enjoy this new feature, and feel free to reach out to us on the developer forum for support, or via Box Pulse to make suggestions on how to improve the feature.




News and stories for working with the Box APIs

Recommended from Medium

Learning GraphQL with Firebase: Part 1

Tracking Click Events In Google Tag Manager

Google Tag Manager variables menu

How To Manage A Shared Codebase

Micro-segmentation techniques

CS 371P Spring 2022: Entry 2

OnClick events in Unity

An Introduction to Hyper API

Big O Notation: The Basics

Big O and bagels

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Barbara Czyż

Barbara Czyż

More from Medium

Versioning in REST APIs

The 4 stages of flakiness (part 3/3): retrying failed tests in Jenkins

Reflections on IAM and Keycloak

Logging in Microservices