Add a Social Identity Provider
Administrators can add a social identity provider so that users can log in to Oracle Identity Cloud Service with their social credentials. Administrators can also allow users to self-register in Oracle Identity Cloud Service if they do not already have an account.
If users don't already have accounts in Oracle Identity Cloud Service, administrators can create an account by using a registration page.
You can configure the social identity provider that you're adding so that users can link to their social accounts manually. You can also prevent users from linking to their social accounts for security or organizational purposes. For example, if a hacker accesses the user's social account, the hacker can't sign in to Oracle Identity Cloud Service to access resources and applications that are protected by Oracle Identity Cloud Service. Or, you may want users to have separate profiles for their social accounts and Oracle Identity Cloud Service user accounts.
-
Facebook
-
Google
-
LinkedIn
-
Microsoft
-
OpenID Connect
-
Twitter
You can add an instance of an out-of-the-box social identity provider type by using either the Identity Cloud Service console or SCIM-based APIs. In this section, you learn how to add a social identity provider from a predefined type by using the Identity Cloud Service console. For more information about how to use SCIM APIs, see REST API for Oracle Identity Cloud Service.
If you don't see the social identity provider type for which you want to add an instance, then you can use SCIM-based APIs to create your own type and customize an icon for it. Through the API mechanism, you define the attributes for the social identity provider type, and then populate these attributes with values when you add an instance.
For example, you can define attributes for a custom social identity provider type that will enable it to retrieve an access token and user information from the social identity provider. When you add an instance of this social identity provider type, you provide the URLs that the social identity provider needs to retrieve this information.
You can also customize social identity provider types for particular identity domains. Suppose you have users in the United States accessing Oracle Identity Cloud Service from one identity domain, and users from India signing in to Oracle Identity Cloud Service from another identity domain. You want only the India-based users to be able to access Oracle Identity Cloud Service with their GitHub social credentials. So, you can customize a GitHub social identity provider type for the India identity domain only.
To remove a social identity provider type and the metadata associated with it cleanly and completely, first, remove the social identity provider type, and then, remove its metadata. Also, if you create a social identity provider type, add an instance of this social identity provider, and assign the instance to an identity provider policy, then don't update or remove the metadata associated with the social identity provider type. If you want to update or remove the metadata, then first remove the social identity provider type from the identity provider policy.
A social identity provider uses an access token to access a resource that's protected by Oracle Identity Cloud Service. This type of token has an expiration date and time. When the access token expires, a refresh token is used to obtain a renewed access token. Unlike access tokens, refresh tokens never expire.
For some custom social identity provider types (for example, Adobe e-Sign), separate URLs have to be provided for the access token endpoint and the refresh token endpoint. When this occurs, you must specify different URLs.
For more information about how to customize a social identity provider type, or to learn how to provide different URLs for the access token and refresh token endpoints, see REST API for Oracle Identity Cloud Service.
Some cloud services have applications that may have to connect to multiple instances of the same social identity provider. For example, for application A and application B, the Facebook social identity provider can be configured as an identity provider along with distinct configuration settings, such as a Client ID and Secret, social registration settings, and so on. To support such scenarios, Oracle Identity Cloud Service enables you to add multiple instances of the same social identity provider with different configuration settings for each instance.
After adding multiple instances of a social identity provider, you can choose which instances can be used to sign in to Oracle Identity Cloud Service by using an identity provider policy.
-
Create an application for the social identity provider; for example, go to the Google developer site to create a Google application.
-
Configure the
redirectUrl
in the application created in Step 1. TheredirectUrl
must have the format:https://<IDCS tenant base URL>/oauth2/v1/social/callback.
Note:
For social identity providers created before release 22.1.49, ensure that the
redirectUrl
doesn't contain port number:443
. If it does, update the existing URL to remove the port number or add a new URL without the port number to the identity provider application using the external provider developers' website.For example, if your configuration looks like the following:
https://<IDCS tenant base URL>:443/oauth2/v1/social/callback
change it to:
https://<IDCS tenant base URL>/oauth2/v1/social/callback
.At the time of this printing, each social identity provider calls these URLs by a different name. See the following list of the social identity providers and the names that they use for the URLs.-
Facebook: Valid OAuth redirect URIs
-
Google and LinkedIn: Authorized redirect URL
-
Microsoft: Redirect URLs
-
Twitter: Callback URL
-
-
Ensure that you retain the
Client ID
and theClient Secret
from the application that you created at the social identity provider. You use this ID and Secret when configuring a social identity provider in Oracle Identity Cloud Service.