Yes! Every Systems Engineer, DevOps engineer, IT Technician (or whatever new title the industry invents next) eventually reaches a point where their job goes far beyond building secure bridges and centralized authentication systems.

Soon enough, problems from beyond the Shire start knocking at your door.

License management, notifications, provisioning without SCIM, database cleanup… the limit is basically whatever challenges you decide to tackle.

In this article, I’ll explain how Okta Workflows helped me solve real operational challenges, and how it can help you do the same.

Let Me Ask You Two Questions

Have you ever wondered:

• How can I optimize licenses for SaaS applications and make sure users are actually using them?
• How can I clean thousands of deactivated users from endless databases?

These were recurring problems in my environment, and I chose Okta Workflows as the platform to solve them.

But first things first.

What Is Okta Workflows?

Okta Workflows is a no-code automation platform provided by Okta that allows you to build automated processes both inside and outside the Okta ecosystem.

You might be thinking:

“Okay, but how can Okta Workflows actually help me?”

Chances are, after reading this, you’ll either discover automation needs you didn’t know you had or realize how many repetitive tasks you can eliminate.

Classic Example

A typical onboarding automation might look like this:

New employee created in Okta →

• Assign Slack or Microsoft Teams channels
• Add required Google Groups
• Send welcome email
• Notify IT and HR internally

The result?

Reduced manual work
Improved security
Fewer human errors

Now that we understand what Okta Workflows can do, let’s look at how I solved two real-world challenges.

1⃣License Management Optimization

If you manage SaaS platforms, you’ve probably faced this question:

“How do we stop paying for unused licenses?”

Users request access to applications, use them for a while… and then abandon them. Their accounts remain inactive, basically as useful as a fax machine in 2026.

The result?

You end up paying €50,000 for 1,000 licenses when only 70% of users are actually active.

That’s a lot of wasted budget.

Most SaaS platforms don’t provide native mechanisms to automatically revoke licenses from inactive users.
This is where Okta Workflows becomes extremely powerful.

Important Consideration: Login Sessions

If your application is integrated with Okta and uses enforced SSO, you can track login activity through Okta System Logs.

However — be careful

Browser session tokens may allow users to access apps without authenticating again for long periods.

If possible, adjust the application’s session expiration settings to a reasonable timeframe. Once this is configured correctly, your login logs become reliable data sources.

Automation Strategy

Here was my approach:

Every day at 9:00 AM CET

1. Review all licensed users.
2. Check login activity.
3. Identify users inactive for more than 30 days.
4. Remove their license, but keep viewer-level access.

Benefits

This approach allows us to:

Maintain a REAL list of active licensed users
Pay only for what we actually use
Preserve limited access for inactive users
Reduce SaaS costs significantly

Applied across multiple high-cost applications, the savings become very noticeable.

Implementation in Okta Workflows

Okta Workflows includes native connectors for many platforms like Figma, Jamf, Miro, Monday, Salesforce, Slack, Atlassian, and more.

And when a connector doesn’t exist, you can always call APIs directly.

In my case, I only needed the Okta connector, since logs and provisioning could be managed centrally.

Trigger Flow

• Runs daily at 9:00 AM CET
• Retrieves all users assigned to the licensed Okta group
• Sends them to a helper flow

Helper Flow

1. Receive users with metadata
2. Query Okta System Logs for latest user.authentication events
3. Filter users inactive for 30+ days
4. Move them from:
   • Licensed group → Unlicensed group
5. Send Slack notification to administrators
   

No deactivation occurs, only license updates. Flow completed.

The entire process now runs automatically in seconds and only requires occasional auditing.

2⃣Database Cleanup Automation

Many organizations accumulate massive numbers of deactivated users.

They remain stored indefinitely:

• Occupying space
• Complicating audits
• And increasing operational noise

Okta environments often contain deprovisioned users still associated with groups years later.

Here’s how I automated cleanup.

Trigger Flow

• Runs daily at 9:00 AM CET
• Retrieves users with DEPROVISIONED status
• Sends them to helper flow

Helper Flow

1. Receive users and metadata
2. Capture current execution date
3. Calculate time difference since deprovisioning
4. Filter users inactive for more than X days
5. Permanently delete qualifying users
6. Notify stakeholders via Slack

Simple, yes, but extremely effective.

Final Thoughts

Automations like these may seem small individually.

But combined, they create a strong, reliable, and scalable infrastructure that dramatically improves operational efficiency.

I’ll continue exploring new possibilities with Okta Workflows, and if you’ve made it this far, I highly recommend giving it a try if you haven’t already.

Thanks for reading!

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.

Let’s be honest — you really can’t trust anything on the network anymore.

With remote work and everything moving to SaaS, we just can’t assume anything is safe – and to be fair, many times, we are the biggest threats to our systems.

That’s when the world started turning to Zero Trust.
You’ve probably heard the phrase:

“Never trust, always verify.”

Sounds great, right? But actually implementing it isn’t easy – and can be a real pain in the neck.

So, what is Zero Trust really?

It’s not a piece of software or a configuration setting. It’s more of a mindset – a different way of thinking about access and security. Something like:

• Identity is everything. Doesn’t matter where you are – it matters who you are.
• Access is earned, not assumed. Being “inside” doesn’t mean you’re in.
• You only get what you need. No more blanket admin rights.
• Logs are your best friend. Because if you’re not watching… someone else might be.

What tools did we use?

Here’s the stack we work with (and personally, it works pretty well for us so far):

• Okta for SSO, MFA, and everything related to identity
• Google Workspace for team productivity and collaboration
• Jamf + Intune to manage all our devices
• Slack and Zoom for everything communication-related
• Confluence to share knowledge and keep everyone in the loop

All these tools are great – but the real challenge is knowing how to use them properly, and that, my friends, is not as easy as it sounds.

Mistakes we’ve made (okay… mostly me)

1. Thinking it was “just an IT project”
   I didn’t involve other teams that were going to be affected. And of course, nobody likes sudden login issues. Better security doesn’t mean people will automatically love the changes.
2. Being too generous with roles
   Giving people more access makes onboarding easier, sure. But later, figuring out who had access to what turned into a nightmare.
3. Believing the official guides would save me
   Not every Okta integration works as described. I had to contact our CSM, open support tickets, and sometimes just rely on good old trial and error.

What I’d do differently now that I know all this

• Talk to the team first. Explain the “why” before changing how they log in. Make sure everyone’s informed.
• Plan roles properly. No improvisation – even if it takes more time, it’s worth it in the long run.
• Document, document, and document. You never know who else will need it. That person might be you at 2 AM.
• Accept this is a journey. It’s not a one-and-done. It needs care and maintenance, always.

Was it worth it?

Absolutely!

We now have better visibility, a more serious onboarding/offboarding process, less reliance on VPNs or “internal trust”, and way more confidence when rolling out new tools.

Thinking of starting this journey yourself?

My advice? Start small. Focus on identity first. Pick one or two tools – and get them right.

Zero Trust sounds big and complicated, but it’s okay to take small steps. And more importantly, it’s okay to make mistakes. If you’re going in the right direction, those small wins will guide you forward.

And seriously… talk to people.
That might just be the most underrated part of doing IT right.