When Hosted Login is provisioned, ​Akamai​ provides you with the following items as part of that process:

• Entity type schema
• Flow
• Customer ID
• Login policy
• Public OIDC login client
• Confidential (configuration) OIDC client
• OIDC confidential client token policy
• Public OIDC client token policy

In this article, we explain what each of these items are used for, and tell you how you can verify that the items really have been provided to you.

Entity type schema

​Akamai​ provides a new schema (or adds to an existing schema, as appropriate) to include all the attributes necessary for Hosted Login to function properly.

How to verify that you have the correct entity type schema

A quick way to verify that you are using a Hosted Login-compatible schema is to complete the following procedure in Console:

1. In Console, click Manage Properties, click the Actions icon next to the name of your application client, and then click Edit.

2. Scroll down the page until you find the user_entity_type setting:

   

   The value of this setting (user) is the name of the entity type schema used by your OIDC login client.

3. Click Manage Schemas and then click the name of the schema retrieved in the previous step.

4. Verify the existence of the following attributes:

   • accountDataRequestTime
   • accountDeleteTime
   • consents.marketing
   • legalAcceptances
   • mobileNumber
   • mobileNumberVerified

If these attributes don’t exist then your entity type is not Hosted Login-compatible. If you have a different schema that does include these attributes then you can assign that schema name to the user_entity_type setting. If you don’t have any Hosted Login-compatible schemas, contact your Identity Cloud representative.

📘

If you need to change the user_entity_type setting in your application client you’ll also need to change the entityType setting in your login policy. Those two values must match in order for Hosted Login to function as expected.

Flow

​Akamai​ provides a new flow specifically for Hosted Login.

How to verify that you have a valid flow

One way to verify (or at least semi-verify) that your flow is Hosted Login-compatible is to complete the following procedure in Console:

1. From anywhere in Console, click Registration Builder.

2. Click the Actions icon next to the name of your flow (by default, Hosted Login uses the standard flow) and then click Edit.

3. On the home page for your flow, click Screens.

4. Verify the existence of the following screens:

   • authRule_acceptLegal
   • authRule_consents
   • authRule_reqAttrs
   • authRule_verifyEmail

If these screens don’t exist then your flow isn’t Hosted Login-compatible. If you don’t have any flows that are Hosted Login compatible, contact your Identity Cloud representative.

Customer ID

​Akamai​ provides your Customer ID. This is used by all Hosted Login operations to point to your core customer account for Hosted Login.

How to verify that you have a customer ID

You can find your Customer ID in Console by completing the following procedure:

• On the Manage Application page, scroll down the list of settings until you find the customer_id setting:

  

  The value of this setting (in this example, e0a70b4f-1eef-4856-bcdb-f050fee66aae) is your customer ID.

Login policy

Login policies help drive the user login and registration experiences. Each of your confidential and public clients must be associated with a login policy. (However, multiple clients can share the same login policy.)

How to verify that you have a login policy

To verify that you have been provided with at least one login policy, complete the following procedure:

1. In Console, click Manage Properties.

2. Click the Actions icon located next to your application client and then click Edit. (Application clients have the same name as their associated OIDC login client.) You can use either your public client or your confidential client: by default these clients share the same login policy.

3. Scroll down until you find the janrainOidcClientId setting:

   

   The value of this setting is the value of your OIDC login client.

4. Use the OpenID Connect Configuration APIs and the /config/clients/{oidcClientId} operation to return the property values of the login client. One of those property values is the login policy ID:

   "loginPolicy": "1ab23c45-6789-0123-d4ef-5g678h90ijk1"

   Copy the value of the loginPolicy property.

5. Use the OpenID Connect Configuration APIs and the /config/loginPolicies/{loginPolicyId} operation to return the property values of the login policy and verify the existence of that policy.

Public OIDC login client

Public login clients are OpenID Connect clients that don’t have client secrets; instead, they rely on a “code challenge” method for communicating with an authorization server. Because there is no client secret to maintain or exchange, ​Akamai​ recommends using public clients for user logins and registrations.

How to verify that you have a public login client

To verify that you have a public OIDC login client, complete the following procedure:

1. In Console, click Manage Properties.

2. Click the Actions icon located next to your application client and then click Edit. (Application clients have the same name as their associated OIDC login client.) The public client should have the words Public Login Client in its name.

3. Scroll down until you find the janrainOidcClientId setting:

   

   The value of this setting is the value of your public login client.

4. Use the /login/token operation to return a configuration access token. You’ll need this access token in order to call the OIDC /config/clients/{oidcClientId} operation.

5. Use the OpenID Connect Configuration APIs and the /config/clients/{oidcClientId} operation to return the property values of the login client. If property values are returned, and if the client type is set to public, then you have a public client:

Confidential OIDC Client

​Akamai​ provides the client ID and client secret for your initial OIDC configuration client. This is a confidential client that has access to all your Hosted Login configuration operations.

How to verify that you have a confidential OIDC client

With your confidential client you need to verify two things: 1) whether the client actually exists; and, 2) whether the client can be used to obtain configuration access tokens. To verify these two criteria, complete the following procedure:

1. In Console, on the Manage Application page, scroll down until you find the confidential_client_id and confidential_client_secret settings:

   

2. Create an API request using the /login/token operation. Configure the request to use Basic authentication, setting the username to the value of the confidential_client_id setting and the password to the value of the confidential_client_secret setting.

3. Make sure the API request includes two x-www-form-urlencoded body parameters:

   • grant_type, which must be set to client_credentials.**
   • scope, which should be set to *:****

4. Make your API call. You should get back an access token that has the scope *:****:

   

OIDC confidential client token policy

The OIDC Configuration APIs (your primary tool for managing Hosted Login) use bearer token authentication: in order to call one of these operations your call needs to include a valid configuration access token. These access tokens are issued by the /login/token operation, which requires Basic authentication: the client ID of your confidential client serves as the username and the client secret acts as the password.

In order to retrieve these access tokens, the confidential client must be associated with a token policy containing one or more configuration scopes; by default, that scope set includes the following:

• openid
• *:**
• *:config/**
• *:webhooks/**

These scopes differ from the token policy scopes associated with your OIDC login clients. Because of that, Hosted Login is provisioned with two token policies:

• One for obtaining administrative access tokens by using a confidential client.
• One for obtaining user access tokens by using a public client.

How to verify that you have a confidential token policy

If you’re able to use the /login/token operation to return a configuration access token then this exercise is a moot point: if your confidential client didn’t have an associated token policy then your call to the /login/token operation would fail. Because of that, your primary interest isn’t so much in determining whether or not your confidential client has an associated token policy but, instead, determining which token policy has been assigned to the client.

To verify which token policy has been assigned to your confidential client, complete the following procedure:

1. Use the /login/token operation to return a configuration access token. You’ll need this access token in order to call the OIDC /config/clients/{oidcClientId} operation.

2. Use the OpenID Connect Configuration APIs and the /config/clients/{oidcClientId} operation to return the property values of the confidential client. One of those property values is the ID of the associated token policy:

   "tokenPolicy": "8cdb3f99-ceee-403d-a01d-daf392e18350"

3. Copy the token policy ID and use that ID and the /config/tokenPolicies/{tokenPolicyId} operation to return the property values of the token policy. The allowedScopes property should look similar to this:

   

If you see a set of scopes similar to the preceding that means that the token policy can be used to return configuration access tokens.

Public OIDC client token policy

Similar to the token policies associated with your confidential clients, your public client must be associated with a token policy. However, that’s where the similarity ends. As noted in the previous section, the token policy associated with the confidential client issues scopes for access tokens exclusively used to call the OIDC Configuration APIs; these scopes (and access tokens) aren’t intended for use with user logins and registrations.

By comparison, your public (login) client must be associated with a token policy that issues user-related scopes. This token policy must issue some combination of the following scopes:

• openid (always required)
• email
• profile
• address
• phone

These scopes dictate the user profile information made available from the userinfo endpoint following a successful authentication. For example, if your token policy issues the openid and email scopes (the default setting) then the email scope can be retrieved from the userinfo endpoint. If you’d like to be able to retrieve the address scope from that endpoint you’ll need to add the address scope to your token policy.

Scopes are also used to specify the default time-to-live values for your access tokens and refresh tokens.

​Akamai​ provides you with a public client token policy.

How to verify that you have a public client token policy

To verify that your public OIDC client has been associated with a valid token policy, complete the following procedure:

1. In Console, click Manage Properties.

2. Click the Actions icon located next to your application client and then click Edit. (Application clients have the same name as their associated OIDC login client.)

3. Scroll down until you find the janrainOidcClientId setting:

   

   The value of this setting is the ID of your OIDC login client.

4. Use the OpenID Connect Configuration APIs and the /config/clients/{oidcClientId} operation to return the property values of the login client. One of those property values is token policy ID:

   "tokenPolicy": "1ab23c45-6789-0123-d4ef-5g678h90ijk1"

   Copy the token policy ID

5. Use the OpenID Connect Configuration APIs and the /config/tokenPolicies/{tokenPolicyId} operation to return the property values of the token policy.