Okta

Paminga integrates with Okta in two directions. Single sign-on lets your team into Paminga with their Okta credentials — from the Paminga login page or straight from their Okta dashboard. Provisioning goes the other way: Okta creates, updates and deactivates Paminga users for you, so someone's Paminga access follows their employment without anyone filing a ticket.

Add the Paminga Integration to Okta.

Supported Features

Feature	What it does
SP-initiated SSO	Your users start at the Paminga login page and sign in through Okta
IdP-initiated SSO	Your users click the Paminga tile on their Okta dashboard and land in Paminga
SCIM 2.0 provisioning	Okta creates users, pushes profile changes, and deactivates accounts
Group push	Okta groups become Paminga global roles
Require SSO	Make Okta the only way into your account

Provisioning runs one way. Okta is the source of truth and Paminga is the target, so Import — pulling users or groups out of Paminga and into Okta — isn't supported, and nothing under Okta's Provisioning > To Okta applies.

Prerequisites

You need administrator access to your Okta organization, and a Paminga user who can manage integrations — that's the Integrations permission, which comes from a role. Without it, Settings > Account > Integrations tells you that you don't have permission and there's nothing on the page to configure.

Everything on the Paminga side lives in one place: Settings > Account > Integrations > Okta SSO. Your Login/Security Policy page shows the connection at a glance and links straight here.

Configuration steps

Setup runs in three parts: add the Paminga integration in Okta, hand Paminga the credentials Okta gives you, and tell Paminga which email domains belong to your organization. Do them in that order — each one needs something from the step before.

Add Paminga in Okta

Sign in to Okta as an administrator.

1. Go to Applications > Applications and click Browse App Integration Catalog.
2. Search for Paminga and click Add Integration.
3. On General Settings, label the application however your team will recognize it.
4. Set Paminga API host to the host your Paminga account uses:
   • api.paminga.com — US accounts, which sign in at app.paminga.com
   • api.eu.paminga.com — EU accounts, which sign in at app.eu.paminga.com
5. Click Done.
6. On the Assignments tab, give access to the people and groups who should reach Paminga.
7. On the Sign On tab, copy the Client ID and Client Secret.

The redirect URI, the initiate login URI, the scopes and the grant type are all preconfigured by the integration, and they follow the host you picked in step 4. You don't enter them, and there's nothing to fix if they look unfamiliar.

note

The Paminga API host you choose in step 4 is the one setting that differs between customers. It tells Okta where your Paminga account lives, and everything else the integration does — single sign-on and provisioning both — is built from it. Get it wrong and neither one works, so if you're unsure, check the address you sign in to Paminga at.

Connect Okta to Paminga

In Paminga, go to Settings > Account > Integrations, find the Okta SSO card and click Configure. Enter:

• Okta Org URL — your Okta organization's address, such as https://yourcompany.okta.com
• Client ID — from step 7 above
• Client Secret — from step 7 above

Click Save. The rest of the Okta settings appear once Paminga has credentials to work with.

Rotating Your Client Secret

If you rotate the secret in Okta, enter the new value in the Client Secret field and save. Leave that field blank when you're changing something else — an empty field means "leave the secret as it is", not "clear it". Paminga never displays a stored secret back to you, so there's nothing to copy out; keep your own record in Okta.

Route Your Email Domains

Add every email domain your team signs in with, such as yourcompany.com.

This is what makes the Paminga login page work. When someone enters their address and chooses to sign in with Okta, Paminga matches the domain to your account and sends them to your Okta organization. Without a matching domain there's nowhere to send them, so sign-in fails.

Add each domain separately if your team uses more than one. Domains are exclusive across Paminga — if a domain is already routed to another Paminga account, you'll be told, and we'll sort it out with you.

SP-initiated SSO

The sign-in process starts from the Paminga sign-in page — https://app.paminga.com for US accounts, or https://app.eu.paminga.com for EU accounts.

1. From your browser, go to the Paminga sign-in page.
2. Enter your work email address in the Email Address field.
3. Click Sign In with Okta.
4. Authenticate with Okta, if you don't already have an active Okta session.

If your credentials are valid and you have a matching Paminga user, you're signed in and land on your Paminga dashboard.

The address you enter is what tells Paminga which Okta organization to send you to, so it's required before the button will do anything — that's the domain routing you set up in Route Your Email Domains. Enter an address and click the button again if Paminga asks for one.

IdP-initiated SSO

Users click the Paminga tile on their Okta dashboard and land in Paminga signed in. Nothing extra to configure.

note

Okta authenticates the person; it doesn't create their Paminga account. This applies to both sign-in flows: a user who authenticates through Okta without a matching Paminga user won't get in. Either create your users in Paminga first, or turn on provisioning and let Okta create them for you.

Require Okta Single Sign-On

Turn this on and Okta becomes the only way in. Paminga passwords stop working, and so do passkeys — anything that would let a user reach Paminga without passing through your Okta policies. Most organizations that adopt SSO want this; it's the difference between offering SSO and actually enforcing it.

One deliberate exception keeps a configuration mistake from locking you out of your own account: Paminga Team Members retain access, so our support team can help you recover.

Users who try to sign in another way are told their organization requires Okta, rather than being left guessing at a rejected login.

Automate User Provisioning with SCIM

Provisioning connects your directory to your Paminga user list. Okta does the work:

• Create users — a new hire in the right Okta group gets a Paminga account
• Update profiles — name, job title and phone changes flow through
• Deactivate users — someone who leaves loses Paminga access, and any active Paminga session stops working immediately
• Push groups — Okta groups become Paminga global roles, so access level travels with group membership

Deactivation is reversible. Okta switches an account off rather than deleting it, so reactivating restores the same user with their history intact.

Generate a Token in Paminga

In Paminga, under User Provisioning (SCIM), give the token a name you'll recognize later — "Okta provisioning" is fine — and click Generate Token.

Copy the token immediately. It's shown once and nowhere else; Paminga keeps only a protected copy it cannot reverse. If you lose it, generate a new one and revoke the old one.

Paminga also shows your SCIM Base URL in this section. You don't need to enter it in Okta — the integration already knows it from the Paminga API host you set during setup — but it's worth a glance if provisioning won't connect, because it shows which host Okta will be talking to.

Turn On Provisioning in Okta

In Okta, open your Paminga application and go to the Provisioning tab.

1. Click Configure API Integration and select Enable API integration.
2. Paste the token you generated into API Token.
3. Click Test API Credentials to confirm Okta can reach Paminga, then Save.
4. Under Provisioning > To App, click Edit and enable Create Users, Update User Attributes and Deactivate Users.
5. To map access levels, use the Push Groups tab to push the Okta groups that should become Paminga roles.

Where Pushed Groups Land

Paminga has no "groups" of its own, so a pushed Okta group arrives as a global role. Find it in Paminga at Settings > Account > Permissions, in the Global Roles section — the role carries the Okta group's name. Open it and its Members tab shows who Okta pushed into it.

A role arrives with no permissions attached. That's deliberate: Okta decides who belongs, you decide what belonging means. Grant the role its permissions once, and every subsequent membership change in Okta flows through without you touching Paminga again.

Only people who already exist in Paminga can be members, so let user provisioning create them before you push the group — otherwise the role arrives empty and it looks like the push failed.

Revoking a Token

Revoke a token whenever it's no longer in use, or if you suspect it's been exposed. Revocation takes effect immediately and Okta's provisioning will start failing, so generate and install a replacement first if you're rotating rather than switching provisioning off.

Troubleshoot

Sign-in fails with a generic message. Paminga deliberately returns the same message for every sign-in failure, whether the account doesn't exist, is disabled, or belongs to a suspended Paminga account. Being specific would let an outsider work out who has an account here. The real reason is recorded on our side — contact your Paminga point of contact and we'll tell you what happened.

"Sign In with Okta" asks for an email address. Expected. The address is how Paminga identifies your organization. Enter it and click the button again.

Sign-in works from Okta but not from the Paminga login page. Your email domain probably isn't routed yet. Check Route Your Email Domains.

A user signs in successfully but is told they can't get in. They have no matching Paminga user. Create them in Paminga, or turn on provisioning.

Okta reports a redirect URI mismatch, or sign-in never reaches Paminga. The Paminga API host on the application's General Settings tab is pointed at the wrong region. Set it to match the address you sign in to Paminga at, then try again.

Test API Credentials fails in Okta. Check the Paminga API host on the application's General Settings tab against the SCIM Base URL Paminga shows you — a US host on an EU account, or the reverse, is the usual cause, and it breaks sign-in too. Then confirm the token hasn't been revoked, and that it was pasted without leading or trailing whitespace.

Provisioning works but group membership doesn't appear in Paminga. Group push is separate from user provisioning. Push the groups explicitly on the Push Groups tab.

You pushed a group and can't find it in Paminga. You're looking for a groups list, and there isn't one — pushed groups are global roles. See Where Pushed Groups Land. If the Permissions page isn't in your account settings at all, your account doesn't have the Permissions feature enabled; contact your Account Manager.

A user Okta deactivated can still use Paminga. They can't — deactivation ends active sessions on the next request. If someone still has access, check whether Okta actually deactivated them rather than only unassigning the application.

For anything else, reach out to your Account Manager or your Paminga point of contact.