Hello everyone, I am trying to figure out the correct way of implementing a single-tenant login flow with social login that can work with both web and mobile clients. At the moment I'm using supertokens-node

16.6.8

with core

7.x

. The issue I am facing is that web is working fine, but when trying to login with Google from an iOS client, google is returning

401

with

unauthorized_client

. I was reading the docs at the bottom of this message, but I have the following questions: 1. do I need to provide separate client configurations? 2. can I provide separate client configurations for all social login providers? 3. I see there is a parameter called

clientType

, is it just an arbitrary string? Thanks in advance for supporting! https://supertokens.com/docs/thirdpartypasswordless/custom-ui/thirdparty-login#social--sso-login-for-both-web-and-mobile-apps

hey @davide.debernardi

Hello @rp_st

you should see this section in our docs

sorry @rp_st I was not very clear: we are using React Native, not doing native client implementations. The docs I was checking are exactly on the page you suggest, at the section

Social / SSO login for both, web and mobile apps

.

right

No worries 🙂 Do you know if there is an example available for multiple clients using Google Login? Or is it the very same for all social login providers?

so, if you have mulitple google credentials, you can add all of them on the backend in the cleints array with unique values for clientType for each

ah, ok! I was also missing the client-side part of specifying the clientType! Just one more question, is there any logic for defaulting to a clientType, if none is provided by the client? The problem I have is with releasing this change to production without having downtime (if possible). The current website client is not specifying a clientType, so I'm really wondering if there is a way to avoid temporarily breaking the auth functionality.

yeaa.. there is no easy way. But, what you can do is to make your own middleware on the backend that runs before ours, and in the API calls for authorization url get and signinup POST, you can interceptor the request and add the clientType to the request body before forwarding the reqeust to our middleware.

well ok, that's something to work with at least! Thank you for now!