IDP details
Please enter the following information from the identity provider (IDP) which you want to configure for social login. We’ll use this information in the next steps.
To find out which protocol the IDP follows, you’ll need to check their developer documentation. Every IDP is different, and you will need to search a bit if they do not make it clear up front.
For example, searching through Naver’s developer documentation, you can drill into their Login API specification to find that it appears they follow the OAuth 2.0 protocol:
The standard protocol this IDP follows for login/authentication. Must be one of the three options above. If the IDP does not follow one of these protocols, it cannot be configured for social login.
Please SELECT THE PROTOCOL to gather remaining details.
|
ACTION: If you haven't already, you must create a client or application for the IDP. This is typically done within the IDP's website or developer portal. Every IDP is different, so please follow the prompts or instructions they provide.
For OIDC providers, you may need to provide a callback URL as part of the creation process. Use a placeholder URL for now - e.g. Once you’ve created your client/app within the IDP, please provide the details below. |
|---|
Where to find the Authorization URL depends on the IDP and which protocol they use.
For OIDC providers, it may be found in their developer documentation, like this:
Or it may be found by looking for the authorization_endpoint entry in their discovery document.
Example: https://my.idp.com/oauth/authorize
The URL of the IDP’s authorization server.
For OIDC providers, the Token URL may be found in their developer documentation, like this:
Or it may be found by looking for the token_endpoint entry in their discovery document.
Example: https://my.idp.com/oauth/token
The URL of the IDP’s token endpoint.
For OIDC providers, the Profile URL may be found in their developer documentation, like this:
Or it may be found by looking for the userinfo_endpoint entry in their discovery document.
Example: https://my.idp.com/oauth/userinfo
The URL of the IDP’s user info endpoint. This endpoint is used to retrieve user profile information.
For OIDC providers, the supported Scopes may be found in their developer documentation, like this:
Or it may be found by looking for the scopes_supported entry in their discovery document.
Example: "openid","email","profile","address"
Scopes are the types of user data that can be retreived from the IDP after the user authenticates. For OIDC providers, the "openid" scope is typically required. The additional scopes available depend on the provider.
The scopes must be formatted as a comma-separated list with quotes around each scope, as seen in the Example above. (Do not include brackets around the scopes here.)
In order to connect an IDP with Identity Cloud, you must create an application or client within the IDP’s developer portal. When this is created, an ID and secret should be generated and provided to you within the portal.
Every IDP is different! Some IDPs refer to this as the client or client ID, while others might call it an application or application ID, and still others might use the term API client. Additionally, the format of the ID string can vary.
Example: b5be4e99ec56b125d86d79b2b1020d48
The unique identifier of the authentication client used for authorization. This is a client that you create on the IDP’s developer website.
For security purposes, you cannot enter your secret into this website. Please note the location of the secret - which should be found alongside your client/application ID in the IDP developer portal - so that you can reference it later in this guide.
Example: c6cf5f00fd67c236e97e80c3c2131e59
The secret key of the authentication client used for authorization. This is the secret that pairs with the Client/Application ID above.
|
ACTION: If you haven't already, you must create a client or application for the IDP. This is typically done within the IDP's website or developer portal. Every IDP is different, so please follow the prompts or instructions they provide.
For OAuth providers, you may need to provide a callback URL as part of the creation process. Use a placeholder URL for now - e.g. Once you’ve created your client/app within the IDP, please provide the details below. |
|---|
Where to find the Authorization URL depends on the IDP and which protocol they use.
For OAuth providers, it should be found in their developer documentation, like this:
Example: https://my.idp.com/oauth/authorize
The URL of the IDP’s authorization server.
For OAuth providers, the Token URL should be found in their developer documentation, like this:
Example: https://my.idp.com/oauth/token
The URL of the IDP’s token endpoint.
For OAuth providers, the Profile URL should be found in their developer documentation, like this:
Example: https://my.idp.com/v1/me
The URL of the IDP’s user info endpoint. This endpoint is used to retrieve user profile information.
The unique ID attribute for IDP users may be found in the IDP’s developer documentation, like this:
Tip! Notice that Naver’s identifier attribute is nested within an object called response. This nesting of user attributes is not common, but it is supported by Identity Cloud. In this case, the Identifier Attribute you provide here should be: /response/id
If you test authentication with the IDP, you should see it in the response.
Example: /id
The profile attribute from the IDP that uniquely identifies the user. For example, if the response from the OAuth provider includes a unique identifier named userid, you should enter /userid into this field - the preceding forward slash is required.
Note! If the incorrect attribute is used as the identifier, all users will be logged in as the same account. Make sure to test login with different accounts after configuration is complete to verify the identifier attribute.
For OAuth providers, scopes may not be required. The use and availability of scopes depends on the provider, and may be found in their developer documentation.
For example, Naver does not specify scopes in their developer documentation, so scopes are not needed for this IDP.
Example: "openid","email","profile","address"
Scopes are the types of user data that can be retreived from the IDP after the user authenticates. For OAuth providers, scopes may not be required. The use and availability of scopes depends on the provider.
The scopes must be formatted as a comma-separated list with quotes around each scope, as seen in the Example above. (Do not include brackets around the scopes here.) If scopes are not required by the provider, leave this field blank.
In order to connect an IDP with Identity Cloud, you must create an application or client within the IDP’s developer portal. When this is created, an ID and secret should be generated and provided to you within the portal. Example:
Every IDP is different! Some IDPs refer to this as the client or client ID, while others might call it an application or application ID, and still others might use the term API client. Additionally, the format of the ID string can vary.
Example: b5be4e99ec56b125d86d79b2b1020d48
The unique identifier of the authentication client used for authorization. This is a client that you create on the IDP’s developer website.
For security purposes, you cannot enter your secret into this website. Please note the location of the secret - which should be found alongside your client/application ID in the IDP developer portal - so that you can reference it later in this guide.
Example: c6cf5f00fd67c236e97e80c3c2131e59
The secret key of the authentication client used for authorization. This is the secret that pairs with the Client/Application ID above.
|
ACTION: If you haven't already, you must create a SAML connection where the IDP acts as the identity provider and Akamai Identity Cloud acts as the service provider. This is typically done within the IDP's website or developer portal. Every IDP is different, so please follow the prompts or instructions they provide.
For SAML providers, you may need to provide the following as part of the creation process:
Once you’ve created your connection within the IDP, please provide the details below. |
|---|
Where to find the Authentication URL depends on the IDP and which protocol they use.
For SAML, it is found in the IDP’s metadata file. Look for the <SingleSignOnService> element within this file, and you’ll find it in the Location parameter. Example:
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://my.idp.com/a12b3c4d-ef56-7890-1234-56gh7ijkl8mn/saml2"/>
Example: https://my.idp.com/asdf/saml2
The URL of the IDP’s authentication service. Also known as the Single Sign-On (SSO) URL.
The certificate is found in the IDP’s metadata file. Look for a <KeyDescriptor use="signing"> element within this file, and the nested <X509Certificate>. The certificate is the content of the <X509Certificate> element. Example:
<X509Certificate>MIIC/zCCAeegAwIBAgIQV6EFkhY2gj+sbpdJQAYuyDANBgkqhkiG9w0BAQsFADAgMR4wHAYDVQQDExV2MS5hcGkudXMuamFucmFpbi5jb20wHhcNMjAwMjE0MjEwMTAwWhcNMzAwMjExMjEwMTAwWjAgMR4wHAYDVQQDExV2MS5hcGkudXMuamFucmFpbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5K8hPHcBvYR5qaVQUC5kfLJTDrNm60EUtg4RF9Dgz0Dzo0D+wJ4+IMd+Y4544VmQj8rqyGwteQAVZP5t1v38PlBWc6ukHoRwOBorM1</X509Certificate>
Do not include the <X509Certificate> tags in the IDP Certificate field.
X.509 certificates are sometimes presented with a beginning line that reads -----BEGIN CERTIFICATE----- and an ending line that reads -----END CERTIFICATE-----. Do not include these two lines in the IDP Certificate field either.
Example:
MIIC/zCCAeegAwIBAgIQV6EFkhY2gj+sbpdJQAYuyDANBgkqhkiG9w0BAQsFADAgMR4wHAYDVQQDExV2MS5hcGkudXMuamFucmFpbi5jb20wHhcNMjAwMjE0MjEwMTAwWhcNMzAwMjExMjEwMTAwWjAgMR4wHAYDVQQDExV2MS5hcGkudXMuamFucmFpbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5K8hPHcBvYR5qaVQUC5kfLJTDrNm60EUtg4RF9Dgz0Dzo0D+wJ4+IMd+Y4544VmQj8rqyGwteQAVZP5t1v38PlBWc6ukHoRwOBorM1
The X.509 certificate used by the IDP to sign a SAML assertion.
Tip! It’s a common mistake to make copy-and-paste errors when entering your certificate, such as including spaces or missing the first or last character. If the certificate is incorrect, all user logins with the custom IDP will fail with a 403 error. Please double-check your field value before moving on.