- Identity
- Read-only
Okta and Qastel
See the AI apps behind your Okta single sign-on, and who is assigned to each one.
Why single sign-on is where approved AI lives
The AI tools a company has approved usually sit behind single sign-on. Qastel reads your Okta directory and app integrations, recognises the AI tools among them and shows who has access to each, so your inventory starts from the people and apps Okta already knows.
When a team adopts an AI tool properly, someone adds it to Okta and assigns people to it. That makes Okta the most complete list you have of the AI your organisation has let in, and of who can open it. It is also a list nobody reads as an AI inventory.
Reading the apps and assignments Okta already holds
Qastel reads every active app integration and recognises the AI tools among them: by their Okta Integration Network name when they come from the Okta catalogue, and by their label for the SAML or OIDC apps you built yourself. For each one it reads who is assigned, directly or through a group.
The directory does the rest. Names, emails, departments, job titles and account status come from Okta, so AI activity seen elsewhere is tied to a real person. Okta keeps no history of assignments, so Qastel shows who is assigned now and records, at the next sync, when someone loses access.
The Okta connect dialog open over Qastel's Sources page, on its key step: the public key to copy, the read-only scopes Qastel asks for, and what it never reads
2400 × 1350What you get
Discover, assess, control, comply.
What Okta gives Qastel, at each of the four stages.
Discover
Every AI app behind Okta single sign-on, recognised by vendor and product, including the custom SAML and OIDC apps your teams set up.
Assess
Each one rated for risk, with the number of people assigned to it: a tool three people can open is not the same as one the whole company can.
Control
See who is assigned to each AI app, directly or through a group, so an access review starts with names.
Comply
A dated record of which AI apps your people can reach through Okta, refreshed every four hours.
A read-only service app, with a key only Qastel holds
You create an API Services app in Okta for Qastel and grant it read-only scopes and the Read-Only Administrator role. It signs in with a key pair generated for this connection: Qastel keeps the private key and you paste the public key into Okta. Qastel does not read passwords, MFA factors, sessions or policies, and it cannot change anything in your Okta org.
What Qastel reads
From Okta
- Every user in your Okta org
- The AI apps behind Okta single sign-on
- Who is assigned to each app
Read-only. Nothing is written back.
Connect Okta
Connects through a read-only API Services app you create in Okta. It signs in with a key pair, no password of yours is stored, and nothing in your Okta org is ever changed.
What you need before you start
- An Okta org, reached at its Okta domain (a custom domain is not supported)
- An Okta super admin, to create the app and assign it the Read-Only Administrator role
In Qastel, open Sources, choose Okta, create a key and copy the public key it shows.
In the Okta Admin console, create an API Services app, set its client authentication to a public key and paste the key, grant the read-only scopes, and assign the Read-Only Administrator role.
Back in Qastel, enter your Okta domain and the app's client ID, then connect. Qastel checks the connection and starts the first sync.
See what Okta already knows about your AI.
Read-only, in minutes. Nothing is ever written back.