Okta as IdP (Identity Provider)

In order to use Okta to authenticate with the API, you need an ID token issued by Okta. This means you'll need an Okta account.

Client ID in Okta

The client id is the application identifier and is what Okta uses to determine which apps are allowed to attempt authorization. To get a client id, you'll need to register a client application in Okta via "Create a new app integration". To do so, go to the Okta admin console, navigate to Applications > Applications, and click the "Create App integration" button. This prompts a wizard where you want to choose OpenID Connect (OIDC) as method of sign-in and Single-Page Application (SPA) as application type. Then choose the appropriate configurations for your application, and you'll be given a client id

Then choose the appropriate settings for your application, specifying the Tricent application login/logout redirects. Then create the app integration, and you'll be given a client id. 

The Tricent for GWS web app redirect URIs are 

- `https://app.tricent.com/login/callback`

- `https://app.tricent.com/logout`

Your application should look something like this:

Authorization servers in Okta

The authorization server is the entity that issues tokens to the client application. Okta provides a default authorization server for your organization that can be used immediately after signup. If this suits your needs, the information you need to supply us with to integrate Tricent with Okta, is as follows:

 - Issuer URI: https://{your-okta-org}

 - Authorization server: https://{your-okta-org}/oauth2/v1/authorize

 - Token endpoint: https://{your-okta-org}/oauth2/v1/token

A full overview of the OpenID metadata associated with the Okta application registered can be found at:

https://{your-okta-domain}/.well-known/openid-configuration?client_id={tricent-app-client-id)

But you can also create a custom authorization server for finer grained control, if your Okta org has this feature enabled. To do so, go to the Okta admin console, navigate to Security > API, and click the "Add Authorization Server" button. You can then configure the settings for your authorization server, and you'll be given an issuer URI. In order for Okta users to access the authorization server, you'll need to add a policy with a rule that allows and dictates access to the authorization server. This can be done by navigating to the authorization server, clicking the "Access Policies" tab, and adding a new policy. To your new policy, you'll have to add a rule and specify users, token and scope configuration. 

If you will be using a custom authorization server, note that the server id is added to the oauth2 information:

 - Issuer URI:

https://{your-okta-org}/oauth2/{your-authorization-server-id}

 - Authorization server:

https://{your-okta-org}/oauth2/{your-authorization-server-id}/v1/authorize

 - Token endpoint: 

https://{your-okta-org}/oauth2/{your-authorization-server-id}/v1/token

Similarly, a full metadata overview for your custom authorization server can be found at

https://{your-okta-domain}/oauth2/{your-authorization-server-id}/.well-known/openid-configuration

Previewing access with custom authorization servers

Once you've set up both the client application and the authorization server, you can test user access by previewing the tokens that are issued to a user, if they were to use the authorization server with the client application. From your authorization server, go to the "Token Preview" tab and select the client application you created earlier, using the authorization code grant. Then select a user and check that tokens are issued as expected.

When tokens are issued as expected, you are ready to use Okta as an IdP for the client application.