Selecting the Best Authorization for Your API Integrations

Integrating with an API lets you power up your code by knowing what the API knows and doing what the API can do. The catch is that most APIs can’t and shouldn’t let just anybody access your important resources. Just as humans log in to access resources, programs accessing APIs must obtain proper authorization.

This is a companion discussion topic for the original entry at
1 Like

Hello Okta.

Working with your teams in the forums, it seems that OIN is the best approach for our needs; we’re a fairly popular LXP and we have some common clients that would like to synchronize their Okta directory as learners in our system. We have a current integration with Microsoft Azure AD which uses the same Bearer token process - it was trivial to implement, and I’m hopeful that we can get some guidance on replicating that functionality with Okta.

I have, however, run into some confusion. The nature of “auth servers” isn’t quite as clear as Azure AD which has a single endpoint for all integrations (where the app token identifies tenancy).

So far, I have:

  1. Signed up for a developer edition of Okta, which yields an admin area with a dev-**** hostname
  2. Have gone into Applications > Applications and clicked on Create App Integration in order to get client/secret
  3. I’ve granted this application the scope
  4. I’ve got my base64 token ready to go - but on what hostname do we call /token? We are currently able to call a default endpoint, but the token it yields doesn’t work with the API

If I’ve dug in the wrong direction, perhaps I latched onto the wrong docs. If a reset were owed to the conversation, it’d be a very simple one: We just want to read user directories using bearer tokens.

What’s our fastest track to a proof of concept?

Confused, puzzled, yet thankful!

Hey there @LLXP,

Thanks for continuing the conversation here. Before I get into all the details about how to set up the API Service Integration in the OIN, I encourage you to sign up for the 2nd day of DevDay where these sorts of topics will be covered (link below). If you and your team are in the bay area, you’re also welcome to attend in person.

In your scenario, which is to create an OIN, you’ll want to create an API service that connects to your OIN application. It seems a little counterintuitive, but you’ll first want to start an OIN submission process (but you won’t complete the submission).

  1. Navigate to the OIN Manager to start the submission
  2. Sign in using your Okta account
  3. Press Add New Submission > API Service tab
  4. Enable support for the API service, and press Test in Okta

This creates an API Service Integration connected to your org so you can test it. This application is found in the Okta Admin console in Applications > API Service Integrations. I also added pics just in case it adds further clarity.

Clicking on the integration listing takes you to details about the application. On the General tab, you’ll see the Client ID and Okta Domain to use for requesting tokens.

On the Okta API Scopes, you’ll see the scope you requested as part of the OIN submission step.

When you implement your integration, the domain and Client ID will be unique for each of your customers who add your integration to their org, so providing that info to you will be part of their onboarding process with you.

Let us know how that works for you!

Thanks @alisaduncan - appreciate the thorough instructions. I’m stuck at step 4 - the Test in Okta button is greyed out (disabled) for me, despite having filled the remainder of the form.

Have I missed something obvious?

I had to fill out everything in General Settings tab too, including uploading an App icon before I was able to create to create the test application.

Does the progress checker on the right side of the OIN manager screen show 100% for General and API?

(sorry forgot to tag you, @LLXP . edited to fix)

Pic below