Before looking at the card itself, let us understand the problem it solves.

Apps need to know who you are

Whenever you open an application, it needs more than a yes-or-no answer to “Is this person allowed in?” It also wants to greet you by name, show the right dashboard, send email to the right address, and decide which features you should see. All of that information has to come from somewhere. Without a central source, every app would ask you to type it all again and would store its own copy.

Copies drift apart

When many apps each keep their own copy of your details, the copies slowly stop matching. You change your surname in one place and forget the other nine. Your manager changes, but only the HR tool knows. A phone number is updated in chat but not in the finance system. Over time nobody knows which version is correct, and mistakes follow, such as emails sent to old addresses or access granted to the wrong team.

The simplest honest answer, followed by the details.

The one-sentence definition

An Okta user profile is the collection of information stored about one person inside Okta. It is made of attributes, which are named pieces of information such as first name, last name, email address, department, and job title. Together, these attributes describe who the person is and where they fit in the organization.

Where profiles live

Okta stores profiles in a central database called Universal Directory. You can think of Universal Directory as a smart address book that can hold not only standard details but also any custom details your organization cares about. Every person who can sign in through Okta has exactly one user entry there, and that entry holds their profile.

Profile versus credentials versus account

Three words are often confused, so let us separate them clearly. The profile is the descriptive information about the person. The credentials are the secrets used to prove identity, such as a password or a phone-based approval. The account is the overall entry in the system that ties the profile, the credentials, and the status together. A person can change their profile details without touching their credentials, and the other way around.

flowchart TD
  U[Person in Universal Directory] --> P[Profile Attributes]
  U --> C[Credentials]
  U --> S[Lifecycle Status]
  U --> G[Group Memberships]
  P --> N[Name, Email, Title, Department]
        

A short glossary makes everything after this much easier to follow.

Every Okta profile starts with a standard set of built-in details.

The built-in set

Okta ships with a base profile that already includes the information most organizations need. It covers the person’s names, contact details, work details, and address information. These base attributes exist from the first day, so you do not have to build anything to get started.

The username matters most

Among all attributes, the username, often shown as the login, deserves special attention. It is what the person types to sign in, and it must be unique across the organization. Many companies use the work email address as the username because people already remember it. Because the username identifies the person everywhere, changing it casually can have knock-on effects in connected apps.

Every organization has details that no standard list could anticipate.

Why custom attributes exist

The base set covers common needs, but real companies track many other things. A hospital might need a license number. A retailer might need a store code. A consulting firm might need a billing rate band. Okta lets administrators add custom attributes to the profile to hold these details, so the profile can describe your organization exactly.

Choosing the right data type

Each attribute has a data type, which tells Okta what kind of value to expect. Common types include text, number, true-or-false, and lists of values. Picking the right type keeps data tidy. For example, a “contractor” flag works best as true-or-false, while a cost center code is better as text, since codes can start with zero or contain letters.

Rules that keep data healthy

You can usually decide whether an attribute is required, whether it must be unique, and whether the person is allowed to see or edit it. These small choices matter. A required attribute prevents half-empty profiles. A unique attribute prevents duplicates. Restricting who can edit sensitive attributes prevents accidental or deliberate tampering.

A profile is only as good as the source that fills it.

Several possible sources

Profile information can arrive in a few ways. It can be created by an administrator typing details directly. It can be imported from a file. It can be pulled from a directory such as Active Directory or an LDAP directory. Or, most commonly in larger companies, it can flow in automatically from an HR system. Each of these is called a profile source when it is trusted to supply the data.

The master of each attribute

When more than one source could supply a value, Okta needs to know which one wins. The source that is trusted to be correct is called the master. Organizations often make the HR system the master for work details like title, department, and manager, because HR is where those facts are officially decided. A directory might be the master for something else, such as a network username.

flowchart LR
  HR[HR System] --> OK[Okta Profile]
  AD[Directory] --> OK
  ADM[Administrator Edits] --> OK
  OK --> A1[Email App]
  OK --> A2[Chat App]
  OK --> A3[Finance App]
        

Why mastering matters

Without a clear master, two systems can overwrite each other in a loop, each insisting that its version is right. With a clear master, changes flow in one direction, and conflicts disappear. When a manager changes in HR, Okta updates once, and the apps follow.

A single person can carry more than one profile, and that is by design.

The Okta user profile

This is the central profile we have discussed so far. It lives in Universal Directory and acts as the reference version of the person.

The app user profile

Each connected application can have its own profile for the same person. This app profile holds the attributes that the specific app understands. A chat app may care about a display name and a time zone. A finance app may care about a cost center and an approval limit. The two apps need different shapes of information, so each gets its own app user profile.

Why not share one profile with every app?

Different apps use different names for the same idea. One app says “surname,” another says “family_name,” and a third says “lastName.” If Okta forced a single shape on everyone, none of them would fit. Keeping a separate app profile and translating between them lets each app stay happy.

Mappings connect the central profile to the many app profiles.

What a mapping does

A mapping is a rule that says “take this attribute from here, and put it into that attribute over there.” Mappings can go from the Okta profile to an app profile, which is how Okta feeds apps. They can also go the other way, from an app or directory into the Okta profile, which is how outside systems feed Okta.

Simple copies and small transformations

Some mappings are plain copies, such as copying the email address across. Others reshape the value on the way. For instance, a mapping might combine the first and last names into one full name, or add a company domain to build an email address. Okta provides a small expression language for these transformations, so common reshaping needs no custom programming.

This is where a profile stops being a record and starts doing real work.

Profile attributes decide group membership

Okta can place people into groups automatically using rules based on profile attributes. For example, a rule can say “everyone whose department is Sales joins the Sales group.” When the department attribute changes, the rule re-evaluates, and the person moves between groups without any manual effort.

Groups decide app assignments

Groups are then linked to applications. Belonging to the Sales group might automatically give you the customer tool and the quoting tool. This two-step chain, from attribute to group to app, is the backbone of efficient access management.

flowchart LR
  A[Profile Attribute: Department = Sales] --> R[Group Rule]
  R --> G[Sales Group]
  G --> P1[Customer Tool]
  G --> P2[Quoting Tool]
  G --> P3[Team Chat]
        

Profile attributes inside sign-in tokens

When a person signs in to an app, Okta sends a signed message that confirms their identity. That message can also carry selected profile details, such as email, name, or department. The app reads these details and uses them to personalize the experience or make its own access decisions. Administrators choose exactly which attributes are included, so only what the app needs is shared.

A profile is not frozen. It lives through stages as the person’s relationship with the company changes.

The common stages

Every user in Okta has a status that shows where they are in their journey. A person might be freshly created and not yet active, then fully active, temporarily locked out after too many wrong password attempts, suspended while an investigation happens, or finally deactivated when they leave. The status controls whether they can sign in, while the profile continues to describe them.

stateDiagram-v2
  [*] --> Created
  Created --> Active: Activation completed
  Active --> Locked: Too many failed attempts
  Locked --> Active: Unlocked
  Active --> Suspended: Administrator action
  Suspended --> Active: Restored
  Active --> Deactivated: Person leaves
  Deactivated --> [*]
        

Employees, contractors, and partners rarely need the same details.

User types

An organization may have several kinds of people. Employees have managers and employee numbers. Contractors have agencies and contract end dates. Partners may have company names and sponsor contacts. Okta allows administrators to define user types, each with its own set of profile attributes, so each group gets a profile that fits.

Why this is better than one giant profile

Without user types, you would build one huge profile with every attribute any group could possibly need. Most of it would be empty for most people, and it would be confusing to manage. Separate shapes keep each profile focused and relevant.

A profile contains personal information, so handling it carefully is part of the job.

Collect only what you need

The safest piece of personal data is the one you never stored. Before adding an attribute such as a home address or a personal phone number, ask whether it is truly needed. Fewer sensitive attributes means a smaller target and a lighter compliance burden.

Control who can view and edit

Not everyone should see or change everything. Administrators can control which attributes are visible and which ones people may edit themselves. A person might be allowed to update their own preferred name or mobile number, but never their department or manager, since those drive access.

Share with apps selectively

When mapping attributes to apps, send only what each app genuinely needs. An email tool does not need a cost center. A finance tool does not need a home address. The less you share, the less can leak if an app is ever compromised.

Seeing the profile at work in everyday situations makes the idea stick.

Most profile problems come from the same few habits.

A short checklist that keeps profiles accurate and useful over the long run.

Quick answers to questions beginners ask most often.

Not quite. The profile is the descriptive information about the person. The account is the larger entry that also includes credentials, status, and group memberships.

Yes. Administrators can add custom attributes and choose their data type, whether they are required, and who may view or edit them.

The Okta profile is the central reference version stored in Universal Directory. An app profile is a version shaped for one specific application, filled using mappings from the central profile.

It means Okta treats the HR system as the authoritative source for that attribute. When HR changes the value, Okta follows. Direct edits in Okta would be overwritten by the next update.

Through mappings and provisioning. When a profile attribute changes, Okta can push the new value into connected apps that have been set up to receive it.

Often yes, for safe details such as preferred name or phone number. Administrators can lock down sensitive attributes so people cannot change things that affect their access.

Because attributes describe real facts such as department, location, and role. Using them for rules means access follows reality automatically, instead of relying on manual requests.

The status is usually moved to deactivated, which stops sign-in and triggers removal of app access. The record may be kept for a period according to your organization’s retention policy.

Not required, but often helpful. User types let each group have a profile layout that fits their needs, so fields are relevant and data stays tidy.

It can be, if you collect only what you need, restrict who can see and edit it, and share only necessary attributes with apps. Follow your local privacy rules and involve your privacy team.

We started with a plastic card at a front desk and arrived at the heart of how Okta works. The user profile is the central record of who a person is: a bundle of attributes stored in Universal Directory, fed by trusted sources like HR, reshaped through mappings for each app, and used by rules to decide which groups someone joins and which apps they receive. It moves through a lifecycle from creation to deactivation, and it must be handled with care because it holds personal information and influences access. Understand the profile well, and the rest of Okta begins to make sense.