This might be the article I’ve been most excited to write so far. Now we’re finally getting into the real stuff, and I have to admit, I’m genuinely hyped. I know, I know… I’m a geek

Before We Start

Make sure to check out my previous article, especially if your Okta environment is still a clean slate. You’ll need a few things already set up before diving into this one.

I Have To Need to Integrate an App — How Do I Do It?

Alright, let’s get into it. Before anything else, you need to understand what kind of integration is possible based on the protocol the app supports. These are the protocols you must know. Seriously, tattoo them on your brain if you have to:

• OIDC (OpenID Connect): Built on OAuth 2.0. Let’s apps verify the user’s identity and securely retrieve user info.
• SAML 2.0 (Security Assertion Markup Language): XML-based protocol used to exchange authentication and authorization data between an IdP and a Service Provider (SP).
• SWA (Secure Web Authentication): A form of SSO where Okta injects credentials automatically into login forms. For apps that don’t support OIDC or SAML.
• API Services (OAuth 2.0 / Token-Based Access): Token-based API authentication, allowing apps to access resources on behalf of a user without exposing credentials.

In this article, I’ll focus only on OIDC and SAML 2.0, the two most secure and widely used protocols.

How OIDC Works, and When to Choose It

OIDC is a modern authentication protocol, designed specifically for login flows. It’s perfect for modern web and mobile applications. It gives you structured token flows, signed payloads, and strong session management.

You should choose OIDC if:

• The application natively supports OIDC.
• You’re building your own web or mobile app.
• You need something lightweight, modern, and dev-friendly.
• You want fine-grained control over scopes, sessions, and claims.

How SAML 2.0 Works, and When to Choose It

SAML 2.0 is a well-established standard, especially in enterprise environments. It may be older, but it’s rock-solid for corporate SSO and has amazing documentation and tooling.

You should choose SAML 2.0 if:

• The app is enterprise-grade.
• You want a combined integration with SCIM provisioning (big win).
• You need XML-based authentication with certificate signing.
• You want something mature, stable, and well-supported.

1⃣ Case 1: Integrating My App Using OIDC

So you’ve decided OIDC is the best fit. Great! Grab a coffee and let’s walk through the steps.

Create the App in Okta

• Go to your Okta Admin Console
• Navigate to Applications > Applications
• Click Create App Integration
• Choose:
  • Sign-in method: OIDC - OpenID Connect
  • Application type: Web, Single-Page App, or Native (depending on your app)
• Click Next

Configure the App

• App Name: Just a name to recognize the app.
• Sign-in redirect URIs: Where users land after login.
• Sign-out redirect URIs (optional): Personally, I avoid setting this unless necessary, as it can interfere with session management across apps.

Once that’s done, take note of the following:

• Client ID
• Client Secret
• Issuer URl / Authorization Server URL

Now, you’ll need to share this info with the service provider or implement it yourself if it’s your own app. But in this article, we’ll stay focused on the Okta side.

Assign Users to the App

• Go to the app in Okta
• Open the Assignments tab
• Assign users or groups (avoid assigning users, trust me)

Test the Authentication Flow

Always test the login flow end-to-end. I recommend using SP-Initiated Flow (more secure), though IdP-Initiated Flow is also possible.

2⃣ Case 2: Integrating My App Using SAML 2.0

More into the SAML 2.0 route? Let’s get to it.

Create the App in Okta

• Go to your Okta Admin Console
• Navigate to Applications > Applications
• Click Create App Integration
• Select:
  • Sign-in method: SAML 2.0
• Click Next

Configure the App

• App Name: A name to identify the app.
• Single sign-on URL (ACS URL): The app endpoint where Okta sends the SAML response
• Audience URI (Entity ID): Unique identifier of the app
• Name ID Format: Usually EmailAddress
• Application Username: How Okta sends the user (usually Email or Okta Username)

Map SAML Attributes (Optional)

You usually won’t need to change this unless your app expects specific attributes. If it does, you can map them here.

Make sure to double-check this, incorrect attribute mapping is one of the most common reasons for failed SAML logins.

Get the Okta Metadata

Once everything is saved, go to the Sign On tab and copy:

• Identity Provider Single Sign-On URL
• Identity Provider Issuer
• X.509 Certificate

These values are needed to configure your app (Service Provider side) so it knows how to trust Okta.

Assign Users to the App

• Open the Assignments tab in the app
• Assign users or groups

Test the Login Flow

Just like with OIDC, I recommend starting with SP-Initiated Flow for more control.

✚ Extras You Should Consider

These are basic setups to get authentication up and running. But the real power comes when you start adding more layers. Here are a few things I strongly recommend looking into:

• Authentication policies (mandatory!)
• SCIM or JIT provisioning
• Push groups (if your app supports them)

Final Thoughts

If you made it this far, thank you.
This stuff isn’t always easy, but it’s incredibly rewarding once you get it working.

Play around, break things, read docs (both official and unofficial), and keep improving your integration. And don’t stop there, enforce security policies, access controls, and build something robust, scalable, and secure.

Thanks for reading!

You’ve just acquired Okta and have no idea where to start.

You’re ready to roll up your sleeves and start integrating applications, but wait! Your tenant is empty. If you don’t lay down solid foundations, you might regret it later.

Here’s what I would do if I had to start from scratch today:

Make Sure You Have a Profile Source

Okta is a powerful tool, but it’s useless without users.

There are many ways to create users in Okta, but in my opinion, the most powerful one is connecting a Profile Source.

There are tons of available options: Workday, BambooHR, Active Directory, LDAP, UKG, and more.

Connecting a source of truth from your HR systems allows you to sync valuable information automatically. This data can be leveraged later for workflows, group assignments, and more.

Tip for smaller companies: You can also use Okta Direct Input. While it’s not ideal and I wouldn’t recommend it, it can work if you don’t have other options — but treat it as a last resort.

Map Every Attribute You Can

Once your source is connected, it’s time to take full advantage of the incoming data.

Map every attribute you can, even if some seem irrelevant now. Trust me, you never know when you’ll need them.

Start with the essentials:

• team
• department
• location
• division
• manager
• office

The more metadata you collect, the more powerful your automations and policies will be.

Create Dynamic Groups

Now that you have user data, it’s time to put it to use.

Dynamic groups let you assign users automatically based on attribute-based rules. For example:

• HR Department
• Finance Team
• Barcelona Office
• US Employees
• IT Support

You don’t need to manually manage membership. Any changes in your source of truth will be reflected in Okta, and users will move in and out of groups automatically based on the defined logic.

Define Access Roles

You won’t be the only one managing Okta.

Set up access roles based on each person’s responsibilities:

• Read-only Admin
• Group Membership Admin
• Application Admin
• Super Admin (only if absolutely necessary)

This step takes a bit of time, but it’s worth it. Delegating access properly reduces risk and improves operational efficiency.

Define Authentication Policies

Security should always be a top priority.

Set up authentication policies tailored to your applications. Not all apps are created equal, accessing Salesforce is not the same as accessing Udemy.

I recommend:

• Enforcing 2FA
• Applying IP restrictions
• Restricting access by device (if capable)

Be strict, especially with critical systems. Better safe than sorry.

In Summary

These five steps will help you build a strong, reliable tenant, ready for growth, app integration, and secure daily operations.

As for app integration… we’ll save that for another post.