Okta - Integrations - Idura Verify Documentation
Idura
  1. Integrations
  2. Okta

This tutorial demonstrates how to integrate Idura Verify with Okta. The following steps are required to complete your first login:

  1. Register your Okta tenant in Idura Verify
  2. Configure your OAuth2 flow
  3. Create Idura Verify identity provider in Okta
  4. Integrate your application with Okta

In the following you will be configuring first Idura Verify, then Okta. Once configured, you may test that everything works from Okta.

The setup requires a bit of switching back-and-forth between Idura and Okta's respective management dashboards, so we recommend that you have them open simultaneously to make the process really smooth.

Before you get started, you will need the following information:

  • The callback URL for your Okta tenant - this will depend on the DNS name you use in Okta for running your logins. The value might look something like https://your-company-name.okta.com/oauth2/v1/authorize/callback, but check your Okta settings to make sure. We'll use acme-corp as a replacement for your-company-name in this tutorial.
  • [Optional] The post_logout_redirect_url for your Okta tenant.

​
Register your Okta tenant in Idura Verify

First, create a new application for your Okta tenant in Idura Verify. This is done via the Idura Dashboard.

Register Application

Once the application is created, you'll need some of its details for configuring Okta to communicate with Idura Verify. Gather the following information from the application settings:

  • Client ID to identify your Okta tenant to Idura Verify. We chose urn:idura:samples:okta for this example.
  • Domain on which you will be communicating with Idura Verify. We used acme-corp.idura.broker.
  • Client secret which Okta needs to fetch actual user information from Idura Verify during login. The secret is generated when you configure the OAuth2 code flow for your application.

If you plan on using single sign-on, you must also register your Okta post_logout_redirect_url as a redirect URL in your Idura application, so you can run single logouts.

​
Configure the OAuth2 code flow

If you are registering a new application, please save the initial configuration first.

After saving, you can configure the OAuth2 Code Flow for this application by following the three steps:

  1. Go to the OpenID Connect section of your Application settings and Enable OAuth2 Code Flow. OAuth2 client secret
  2. Copy the generated client secret. Note that this is the only time you will be shown the actual value of the client secret. Idura only stores this as a hashed value, which means you cannot retrieve the value once it has been generated and stored. OAuth2 client secret
  3. Set the user info response strategy to plainJson to enable retrieval of plain JSON user information from the /oauth2/userinfo endpoint. OAuth2 code flow Note that some libraries do not support the final userinfo request. In those cases, you will need to fetch the user data directly from the token endpoint as opposed to the userinfo endpoint. You can do this by choosing fromTokenEndpoint as a User info response strategy. User info response strategy

Idura Verify supports four modes for retrieving user information:

  • Plain JSON object (plainJson): User information is returned from the userinfo endpoint as a standard JSON object.
  • Signed JWT (signedJwt): User information is returned from the userinfo endpoint as a digitally signed JSON Web Token.
  • Signed and encrypted JWT (signedAndEncryptedJwt): User information is returned from the userinfo endpoint as a signed and encrypted JSON Web Encryption(JWE) object.
  • Directly from the token endpoint, embedded in the id_token (fromTokenEndpoint). The fromTokenEndpoint flow is not standard, but can be useful if you are working with a product that does not call the userinfo endpoint.

​
Add a new Identity Provider in Okta

These steps are based on Okta developer documentation for configuring an OIDC Identity Provider.

  1. In your Okta Admin Console, go to Security > Identity Providers.
  2. Select Add Identity Provider, then select OpenID Connect IdP. Click Next.
  3. Fill in the Configure OpenID Connect IdP form similar to the following example:
Example identity provider

Assuming that your Idura Verify domain is acme-corp.idura.broker, configure the fields as follows:

  1. Name: A name for Idura Verify identity provider. It's entirely up to you.
  2. Scopes: openid will suffice.
  3. Client ID: urn:idura:samples:okta (the Client ID/Realm value from your Idura Verify application).
  4. Client Secret: The secret generated for you by Idura Verify during the OAuth2 code flow setup.
  5. Issuer: https://acme-corp.idura.broker/ (the Idura domain your application is registered on).
  6. Authorization endpoint: https://acme-corp.idura.broker/oauth2/authorize?acr_values=urn:grn:authn:dk:mitid:substantial
  7. Token endpoint: https://acme-corp.idura.broker/oauth2/token
  8. JWKS endpoint: https://acme-corp.idura.broker/.well-known/jwks
  9. Userinfo endpoint: https://acme-corp.idura.broker/oauth2/userinfo; If you specify the optional Userinfo endpoint, make sure your Idura Verify application user info response strategy is set to plainJson.

This setup assumes you are planning to authenticate your users with the Danish MitID. If you need other eIDs, replace the value of the acr_values parameter in the Authorization endpoint, or set up several Identity Providers in your Okta tenant - see below for a list of supported values.

​
Supported acr_values

Idura Verify supports a range of country and bank specific eID services. They are all accessed through the same endpoints, e.g. https://<YOUR COMPANY>.idura.broker/oauth2/authorize

To pick the login method you must set the acr_values parameter on the authentication request in order to choose the type of authentication you want. How you set this query string parameter varies with programming platform and your OpenID Connect library of choice.

The current list of possible values is:

Login methodacr_values
Norwegian BankID
Mobile or Web (user choice):urn:grn:authn:no:bankid
Norwegian Vipps Login
Login with Vipps app:urn:grn:authn:no:vipps
Swedish BankID
All options (user chooses):urn:grn:authn:se:bankid
Same device:urn:grn:authn:se:bankid:same-device
Another device (aka mobile):urn:grn:authn:se:bankid:another-device
QR code:urn:grn:authn:se:bankid:another-device:qr
Danish MitID
Level low:urn:grn:authn:dk:mitid:low
Level substantial:urn:grn:authn:dk:mitid:substantial
MitID Erhverv (MitID Business):urn:grn:authn:dk:mitid:business
Finnish Trust Network
BankID:urn:grn:authn:fi:bank-id
Mobile certificate (Mobiilivarmenne):urn:grn:authn:fi:mobile-id
Both of the above:urn:grn:authn:fi:all

​
Test users

Most eIDs distinguish between real users and test users.

Real users represent actual individuals who authenticate on your website, providing real personal information such as their name and typically a Social Security Number (SSN).

Test users are fictitious identities used for development and testing. Depending on the eID, you can either create your own test users or use pre-existing ones provided by Idura.

For instructions on creating test users for each eID, please refer to Test user guides.

​
Integrate your own application with Okta

How to integrate your application with Okta depends on the technology you are working with. Refer to the Okta developer documentation for more details.