What type of OAuth Integration should I register?

Are you an Oracle Aconex Customer?

Oracle Aconex Customers are paying or non-paying organizations that use Aconex for their daily project management activities.  Customer integrations are built for internal use by the Customer and their employees.

As an Aconex customer, you most likely intend to build an integration with Aconex that runs on a scheduled basis to access your organization's data without any user interaction.

Two different types of integrations are suitable:

• A Non-Interactive Integration is the most secure and most flexible option and is the recommended approach.  You request an access token by making a single API call to the Lobby with a signed User Assertion that identifies the desired user account.  This option gives you the flexibility to request a token for any user within your organization at run-time.  When you register your integration, you upload a public certificate that Lobby uses to verify that the User Assertion is signed by you.  This gives you ultimate security.  Learn more about Implementing OAuth in a Non-Interactive Integration.
  
  
• A User-Bound Integration is the easiest option to implement and is bound to a single Lobby user account.  When you register your integration, you specify a Lobby user account from within your organization that is bound to your integration.  You request an access token by making a single API call to the Lobby.  Specify the desired Aconex user account if the Lobby user account is linked to more than one Aconex user account.  Learn more about Implementing OAuth in a User-Bound Integration.

Alternatively, you may build an application for your users that integrates with Aconex.  Users must sign into Lobby to authenticate themselves and authorize your application to access their Aconex data.

Your application is either:

• A Web Server Application, which is a server-side user application delivering a user interface in a web browser.  Requesting an access token is a two-step process.  First, your application prompts the user to sign into Lobby in the browser and authorize your application.  Lobby returns an access code that your server-side application exchanges for an access token.  Learn more about Implementing OAuth in a Web Server Application.
  
  
• An Installed Application, which is a user application that is installed by the user onto their device.  Typical examples are Windows, macOS, iOS app, and Android apps. A single-page app (SPA) running entirely in a web browser is another example.  Requesting an access token is a two-step process.  First, your application prompts the user to sign into Lobby in the browser and authorize your application.  Lobby returns an access code that your application exchanges for an access token.  As your application is running on the user's device, additional security measures are required and it must implement Proof Key for Code Exchange (PKCE).  Learn more about Implementing OAuth in an Installed Application.

Are you an Oracle Technology Partner?

Technology Partners are vendors that have registered with the Oracle PartnerNetwork (OPN) and who deliver, or intend to deliver, solutions to Oracle Aconex Customers.  Partners build integrations between Aconex and their own software application (or another software application, with approval from the other party) with the intention of entering a commercial arrangement with Oracle Aconex Customers.  Partner integrations can be published for use by Oracle Aconex Customers and their employees.

As a vendor, you deliver an application that allows your customer's users to access their Aconex data within your application.

When using your application, users must sign into Lobby to authenticate themselves and authorize your application to access their Aconex data.

Your application is either:

• A Web Server Application, which is a server-side user application delivering a user interface in a web browser.  Requesting an access token is a two-step process.  First, your application prompts the user to sign into Lobby in the browser and authorize your application.  Lobby returns an access code that your server-side application exchanges for an access token.  Learn more about Implementing OAuth in a Web Server Application.
  
  
• An Installed Application, which is a user application that is installed by the user onto their device.  Typical examples are Windows, macOS, iOS app and Android apps. A single-page app (SPA) running entirely in a web browser is another example.  Requesting an access token is a two-step process.   First your application prompts the user to sign into Lobby in the browser and authorize your application.  Lobby returns an access code that your application exchanges for an access token.  As your application is running on the user's device, additional security measures are required and it must implement Proof Key for Code Exchange (PKCE).  Learn more about Implementing OAuth in an Installed Application.

Are you an Independent Software Vendor (ISV) or System Integrator (SI)?

If you are building a custom integration for an Oracle Aconex Customer, a Customer representative should request registration of the integration with Aconex and should be the one who handles the registration credentials.

Read the section Are you an Oracle Aconex Customer? and provide the required information to the Customer.

If you intend to build an integration with Oracle Aconex that you will make commercially available for one or more Customers, you must join the Oracle PartnerNetwork (OPN) and become an Oracle Technology Partner to request registration of the integration with Aconex.

Read the section Are you an Oracle Technology Partner?

Frequently Asked Questons

Do I need a different OAuth client for each organization?

You should register an OAuth client for each API integration that you build.  You identify which organization(s) can use the integration when you register it.

A User-Bound Integration is bound to a single Lobby user account, but you can link multiple Aconex user accounts to that Lobby account.

 

How do I find my client ID & secret?

If your organization has its own Identity Domain, the client ID and secret can be located in your OCI console.

If not, you will be provided instructions to locate them in the original Service Request.

 

Why did I not get a secret?

The client ID is used to identify the integration and the secret is kept confidential, like a password.

Installed Applications cannot keep a secret confidential, so instead of a secret they use Proof Key for Code Exchange (PKCE) instead.

 

I'm a partner, why can't I register a Non-Interactive Integration or User-Bound Integration?

Your application must get run-time authorization from the user to access their Aconex data.

Non-Interactive Integrations and User-Bound Integrations run without a user present and cannot do this.

 

What did legacy OAuth support?

Legacy OAuth only supported Web Server Applications.