Okta Sign in Widget with Google Social Login

My Okta domain is gloo.okta.com and I am using the sign in widget in a react test app to get familiar with Okta and the capabilities. I have passed parameters to the OktaSignIn call to enable the Google social sign in button and I have configured both the Google API side and configured Google as an IdP in Okta. I’ve followed the Okta product documentation in doing so.

When I click on the Google sign in button, I get the following 400 Bad Request Error:

Identity Provider: Google
Error Code: invalid_client
Description: Invalid value for ‘client_id’ parameter.

with the following URL:

https://gloo.okta.com/oauth2/v1/authorize?client_id=0oadot4jgiWNGLtEn0h7&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Flogged-in.html&response_type=id_token%20token&response_mode=fragment&state=JBpFCejOhIBFfZCGuie6AOEvqoRHpQxG5QSXFfTCgUVIuRHElOhM8XqkTJOOHHlO&nonce=YpzgAhV8FOYbHUyw5JHIodGNUWidCp9pbjtdbo0ylUUiQIqaIMFwHwHaGf3ackAH&display=page&idp=0oap56nd9jHjsdFNu2p6&scope=openid%20profile%20email

I expect some of these query string values, but the client_id field, the one the request seems to be complaining about, I cannot find anywhere…meaning I don’t even recognize client_id of 0oadot4jgiWNGLtEn0h7.

Any hints at what I might be doing wrong.

Clearly I’m having a little trouble explicitly setting the client_id to the proper value. I cannot see where to explicitly pass a client_id as an authParam.

I am obviously having trouble executing on this step in the product documentation:

Complete Your Authorize URL

Thanks for pointing me in the right direction.

You need to create an OpenID Connect Application. Once you do that, you’ll have the client_id for the authorize route.

I think there is a typo in the documentation, it talks about step 4.10. but I pretty sure they meant 4.9.

Let me know if this fixes the problem for you!
Tom

So I have already created that OIDC application and I have the client ID. The problem is that while I thought I was “passing” it in properly…I clearly am not. Can you point me to where I need to be setting the client_id for the authorize route?

More specifically, when the instructions tell me that an Authorize Route is generated with a number of blank parameters that I need to fill in…when using the Widget…where do I fill those in? It’s not like I am creating the HTML link myself…I believe it is being generated for me…so I’m thinking I need to pass the parameters for it’s generation but am doing that incorrectly???

You mean in the widget?

Here is an example:

var oktaSignIn = new OktaSignIn({
  baseUrl: orgUrl,
  clientId: 'smBXcoabniBOUsja0A6b7', // here
  redirectUri: 'http://localhost:3000',
  authParams: {
    issuer: 'default', 
    responseType: 'id_token',
    scopes: ['openid', 'whatever'],
  },
  idps:[
    { type: 'google', id: '0oadrrh812O9sbabE0h7' },
    { type: 'facebook', id: '0oadtgaq74qR0qdD20h7'}
  ],
  idpDisplay: "PRIMARY",
  i18n: {
    en: {
      'password.forgot.email.or.username.placeholder': 'Email',
      'password.forgot.email.or.username.tooltip': 'Email',
      'errors.E0000095': 'Unable to reset password.  Did you put in a valid email?'
    }
  }
});

You may not need to set the issuer, this matters if you are doing Okta SSO, or if you are getting an access token to protect APIs (then you can set it to default).

Let me know any questions,
Tom

Completely tracking with you, Tom.

I am setting the clientID to ‘0oap56i1gwTzug4ov2p6’ exactly where you specify which is the clientID of the OIDC Application.

My confusion is that the clientID present in the query string that the server is complaining about is ‘0oadot4jgiWNGLtEn0h7’ and I don’t recognize it and do not know where it came from???

That is interesting, I haven’t seen that before. Digging in, I see that ID in a gloo developer org on oktapreview. I think there might be something weird going on with either the code reading an old value from somewhere?

Is this react native? Is it possible that the build isn’t taking the new value?

shut my machine down…logged out of everything Okta…fired it all back up and the issue was solved…

So sorry it was one of those phantom issues, but I think your assessment just above is correct…something funky was going on reading an old value or a cached value or a value from elsewhere…

Onward! Thanks

Not a problem! glad you are up and running.