Best Practices from Oracle Development's A‑Team

The Generic OpenID Connect Social Provider in Oracle Identity Cloud Service

Identity Cloud Service (IDCS) supports out-of-the-box the top four social identity providers: Google, Facebook, Twitter and LinkedIn. This allows users to log into IDCS using their social accounts. The social identity providers use OpenID Connect (OIDC) as the federation protocol. OIDC is used not just by social providers; even AWS Cognito supports OIDC while acting as an identity provider. To support other OIDC identity providers, IDCS provides a generic OIDC provider type which can be configured to establish federation between IDCS and the provider. An example of the generic OIDC provider is described in the blog post Federating Oracle Cloud with AWS Cognito where IDCS federates with AWS Cognito using OIDC.

That's good news! So, what is this blog post about? Well, for some OIDC providers, using the generic OIDC social provider in IDCS may result in an error as in the following figure:

Fig 1

Intrigued? The rest of the post goes under the hood to unravel what's happening.

Under The Hood

When you create a social identity provider, whether an out-of-the-box or using the generic template, IDCS creates a record for the provider in its configuration store. For example, I have created a provider in IDCS for AWS Cognito using the generic OIDC template. The provider is named "Amit Cognito".

Fig 2

After hitting the "Save" button above, IDCS creates a record as follows (which I fetched using the REST API).

Fig 3

Note that "name" (3rd attribute) has "Amit Cognito" as the value. Also note the (1st) attribute "serviceProviderName" has the value "OpenID Connect" which reflects that the generic OpenID Connect template was selected to create the provider. The other highlighted attribute (2nd) is "idAttribute" which has a value of "email", and this has direct correlation to the issue depicted in Fig 1 above. The "idAttribute" serves as the matching attribute to match the user accounts in the provider and the IDCS. 

After IDCS completes the OIDC flow with the identity provider ( i.e. the user has successfully authenticated), IDCS fetches user attributes (i.e., OIDC claims) from the Userinfo endpoint. IDCS will look for the matching attribute in the Userinfo response from the provider which here will be "email". If "email" is present in the response, IDCS will match the accounts ("email" in the response with the "username" in IDCS) and let the user log into IDCS - the classic case as discussed in my previous blog post. However, what happens if "email" is not present in the response?

By default, IDCS requires users to have email. This is not surprising since many use cases, especially in the corporate environments, require users to have emails. However, increasingly applications and identity providers do not require email as a required attribute for user accounts. For example, in AWS I have defined the following attribute section for our example provider Amit Cognito.

Fig 4

The attributes are the OIDC standard claims. Although "email" is one of them, I have decided on "preferred_username" as the mandatory claim for user accounts. After successful OIDC flow, the Userinfo endpoint response returns the following:

Fig 5

Cognito returns "preferred_username" as part of the response. Note "email" is not returned in the response. When IDCS does not find "email" in the response, it flags an error as in Fig 1.

The Solution

Disappointed? Please don't be! IDCS has you covered. To handle this use case, two points need to be handled at the IDCS:

i) Configure social IDP with any attribute, not just "email", as the matching attribute (idAttribute in Fig 3), and

ii) Allow user accounts to be created with primary email address as optional.

IDCS supports both the above capabilities - optional email and customizable social providers - which will let you address the issue in Fig 1. That's the subject of my next blog. So stay tuned!


IDCS supports federation out-of-the-box with some of the most popular social identity providers. The social identity providers support OIDC as the federation protocol. In this blog post we looked into a specific use case where email is not present in the user accounts in the OIDC provider. We discussed what issues may arise and what it takes to address it.




Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha