With Okta your team signs in to 1-CP using their familiar company login. The integration runs on OpenID Connect and can operate at two levels: authentication only, or authentication plus profile data. The base setup is identical in both cases.
Responsibility is shared. 1-CP provides the integration details, your Okta administrator creates the app integration and remains its owner.
Sign-in redirect URL: We send it to you, one per environment (production and staging). Enter it exactly as provided. Redirect URIs are case-sensitive, and users see an error if the URI they are sent to is not registered.
App type: OIDC - OpenID Connect, application type Web Application
Grant type: Authorization Code. For web apps this is fixed in Okta.
Scopes: openid, profile, email
In the Admin Console, go to Applications and Resources, then Applications, and click Create App Integration.
Select OIDC - OpenID Connect as the sign-in method and Web Application as the application type.
Enter an app integration name, for example 1-CP SSO.
Under Sign-in redirect URIs, enter the URI you received from 1-CP.
Under Assignments, define who gets access to the app.
After saving, open the General tab. Under Client Credentials you find the Client ID. Choose Client secret as the client authentication method and generate the secret.
Your team signs in via SSO and 1-CP synchronizes no profile data. The standard OIDC scopes openid, profile and email are enough for this.
Important: 1-CP identifies users by email address. Make sure the accounts in scope have an email address maintained in Okta.
On top of sign-in, 1-CP takes master data from your Okta directory into the user profile. This saves manual maintenance in 1-CP and keeps names and contact details current.
Prerequisite: The attributes you want transferred must be populated in the Okta user profile, in particular first name, last name and email address. If an attribute is missing, the corresponding field in the 1-CP profile stays empty.
Depending on the scope you want, an additional scope or a custom claim may be needed in Okta. Which fields are transferred in your setup, and what has to be configured for that, is agreed during onboarding. Reach out via the help widget and we will raise a ticket and work it through with you.
clientId – the Client ID from the General tab of your app integration
clientSecret – the generated client secret
domain – your Okta tenant domain, for example example.okta.com. If you use a custom URL domain, provide the domain shown in the app's issuer.
authorizationServerId – the ID of the authorization server 1-CP should talk to (see the next section)
The client secret is a sensitive credential. Please do not send it by email, use an agreed secure channel instead.
Okta has two types. The org authorization server exists in every Okta org and, per Okta, is sufficient for plain SSO. Custom authorization servers allow your own scopes, claims and access policies.
A custom authorization server with the ID default is pre-configured if your org uses Okta's API Access Management product. In production environments that is a paid add-on, so it is not present in every org. You can see which servers exist in the Admin Console under Security, API.
In most cases default is the right value. If you use a dedicated server, provide its ID in the aus... format. If you are unsure which server fits your org, reach out via the help widget. We will raise a ticket and check it together before you change anything.
Separate production and staging. Create a dedicated app integration with its own secret per environment. A leaked staging secret then never affects production, and both environments can be retired independently.
Control access through groups. Assign the app specifically to the groups that should use 1-CP rather than to everyone in the org.
Plan rotation without downtime. Okta supports a second client secret, so you can rotate without breaking sign-in in between.
No wildcards in redirect URIs. Okta discourages them because tokens can end up on unexpected pages. Our URIs are absolute, so wildcards are not needed.
Start with level 1. Get sign-in working cleanly first, then extend to profile data if needed. This narrows down potential sources of error.
Stuck somewhere, or have a requirement not covered here? Reach out via the help widget, we will raise a ticket and support the setup.
