OAuth Authentication

DISCLAIMER

This page contains third-party references. We strive for our content to always be up-to-date, however, the content referring to external vendors may change independently of Omada. If you spot any inconsistency, please report it to our Helpdesk.

Omada Identity supports OAuth authentication through the use of bearer tokens for access to the Omada Identity website. The OAuth implementation supports various grant types, including username and password grants and client secret grants. The client's application that connects to ES must request a bearer token with a third-party Identity Provider (IdP) and provide the token as a bearer token in the HTTPS Authorization header.

Access tokens issued in response to a client credentials token requests are used for machine-to-machine communication where it is required not to store or embed usernames and passwords. By default, tokens based on client secret are not linked to Omada Identity's users; in consequence, users must be created with usernames that are the sub-claims of the access token. The service user must be granted a minimal authorization level needed.

By convention, the main Application registration in the IdP (the one used in the OpenID Connect configuration) cannot be used with client secret grants, i.e., one new application registration must be created per client application that connects to ES.

OAuth for OData API

info

The OData API in Omada Identity Cloud can be utilized with a Client Credentials flow, with OAuth authentication in customer’s own Azure tenant.

Prerequisites

To set up and configure such an authentication flow it is required to:

• In Omada Identity, applicable Data Object Type(s) must be enabled for OData:

  

• In Omada Identity Cloud Management Portal, authentication must be configured to use OpenID and Azure AD:

  

• Azure App for interactive authentication (hereafter Azure App OpenID) must be configured to use OpenID for authentication.

• A tool for manually sending calls to Azure and Omada APIs will be needed.

note

We recommend downloading Postman. You can download it for free here.

Creating Azure App for OAuth authentication flow

A second or additional Azure App OAuth must be created, in the same tenant where Azure App OpenID is present.

1. In Microsoft Azure, go to App Registration.

   

2. Create a new App Registration.

   

3. Go to Manifest and edit so that “accessTokenAcceptedVersion”: 2.

   

4. Go to Certificates & secrets and create New Client secret.

   

5. Copy (make a note of) values generated for:

   <ClientSecret>
   
   Application (client) ID = <ClientID OAuth>
   
   <OAuth 2.0 Token Endpoint>

   

Modify configuration of Azure App OpenID

1. Navigate to Azure App OpenID.

2. Copy (make a note of) value of Application (client) ID = <ClientID OpenID>.

3. Click Add an Application ID URI.

   

4. Click Set and enter the API URL, as follows:

   • API://[id of the OData AppRegistration]

5. Ensure that accessTokenAcceptedVersion”: 2 is in the App’s Manifest.

Generating a bearer token

1. In Postman, create a new POST request, with four added Headers, using values from step 3:

   

2. Send Request, then copy the BearerToken returned:

   

3. Using a web browser, navigate to URL: jwt.ms..

4. Paste the BearerToken, and click on the Decode Token button.

   

5. Verify that values are correct:

   “aud” = <ClientID OpenID>
   
   “azp” = <ClientID OAuth>

   

Creating Omada User

1. In Omada Identity, create a new User with Username = ClientID OAuth.

   

2. Add applicable Group memberships, allowing access to OData. For example:

Verifying authentication flow and access

In Postman, create a new GET request, using coded BearerToken for authentication, and applicable URL as seen below:

Response: