for google auth, the access_token is not being recognised. It only recognises id_token?

[elimau]

New Issue Checklist

• [x ] I am not disclosing a vulnerability.
• [x ] I am not just asking a question.
• [x ] I have searched through existing issues.
• [ x] I can reproduce the issue with the latest version of Parse Server.

Issue Description

I perform the Parse.user's linkWith request
await user.linkWith('google', payload)
where the payload is
const payload = { authData: { id, access_token } }

It fails with id token is invalid for this user error message

From this documentation, it seems access_token is supported for google.
https://docs.parseplatform.org/parse-server/guide/#google-authdata
Also, reading this issue, it seems access_token is supported.
#4698

Yet, when i read the code of the google auth adapter, it seems it only supports id_token. There is no reference to access_token in that file.

parse-server/src/Adapters/Auth/google.js

Line 64 in 1594afe

async function verifyIdToken({ id_token: token, id }, { clientId }) {

Was it something that used to be supported but no longer supported?
Am I reading something wrong?

Environment

Server

• Parse Server version: 4.5.0
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): back4app

[mtrezza]

Thanks for reporting. Is this related to #6849?

[elimau]

Hi,
yes, it is the same problem.
But i'd like to further explain the problem I am experiencing.

My two constraints are:

• Parse.User.linkWith('google', payload) requires id_token and id to be called successfully
• I can get either the access_token or the id_token from google oauth process.
  However for some reason (even if I put responseType="token id_token" when the oauth authentication happens),
  I am unable to get both. Hence I have a choice here to get one or the other.

So there are two paths of progress.

1. If I get access_token:

• I have to create a backend parse function endpoint which queries google to get the id of the user.
• i.e.

const oauth2 = google.oauth2('v2')
const userInfo = await oauth2.userinfo.get({}). <-- This userinfo contains `id`

Now i have the id but I do not have id_token so I can not use linkWith('google', payload) successfully.

2. If I get id_token:

• How can I get id?
• Because I do not have id, I still can not use linkWith('google', payload) successfully.

firebase
When I look at the firebase implementation, I do not have to supply id to login.
e.g.

import firebase from 'firebase'
const oAuthCredential = firebase.auth.GoogleAuthProvider.credential(id_token, access_token)   <-- one or the other is required. Both works.
const userCredential = await firebase.auth().signInWithCredential(oAuthCredential). // success.

So there is a few resulting questions:

• Is it possible to make linkWith('google', payload), not require the id field (like how firebase works)?
• Is there a way I can get id using the id_token from google?
• Is it possible to make linkWith('google', payload) work with access_token and also it does not require id?

Thanks.

[mtrezza]

@SebC99 Do you have any idea how we could address this, and maybe close it together with #6849?

[SebC99]

I don't know anything about using google signing on the web, but a quick look at the docs it is said:

if (auth2.isSignedIn.get()) {
  var profile = auth2.currentUser.get().getBasicProfile();
  console.log('ID: ' + profile.getId());
  console.log('Full Name: ' + profile.getName());
  console.log('Given Name: ' + profile.getGivenName());
  console.log('Family Name: ' + profile.getFamilyName());
  console.log('Image URL: ' + profile.getImageUrl());
  console.log('Email: ' + profile.getEmail());
}

So I guess the user id is in its profile.

But otherwise, it's quite easy to remove the server side check on that id, as we only need to remove these lines:

  if (jwtClaims.sub !== id) {
    throw new Parse.Error(Parse.Error.OBJECT_NOT_FOUND, `auth data is invalid for this user.`);
  }

or at least add a case where the id is undefined.

I still have no clue on why #6849 isn't passing the tests, but otherwise I'm happy to include this in the PR

[elimau]

@SebC99 Look here:
https://auth0.com/docs/tokens/id-tokens/validate-id-tokens
It tells what are the important things to check for in the id_token.

It looks like the google adapter is doing the important checks against the JWT for alg, iss and aud.

So I also agree that the id is not necessary.
Sounds good to me!

Regarding your comment about the tests not passing, I could not see any pull requests against that #6849 . Do you have a link to the test you mention that is failing?

[SebC99]

@elimau sorry the PR was #6992

[andrewalc]

Seeing the same issue, had old code that passes a google access_token to linkWith in 4.2.0, now on 4.10.3 and the google access_token is not being accepted by linkWith. switching to the id_token works fine.

[PavelBT]

Change de Auth data, not to { id, access_token } try with { id, id_token }, works for me!!!!

[R3D347HR4Y]

The user gets created fine with {id, id_token}, it doesn't with access_token
However I don't get any sessionToken using linkWith or loginWith
I even tried with Postman, so it's not a client issue, no sessionToken gets sent so I can't log in to the User that was just created...
Anyone got the same problem?

[REPTILEHAUS]

I opened the original issue on this 4 years ago :D currently hitting it again, is it not possible to support both id_token and access_token ?

[mtrezza]

In light of #9667, please review the updated functionality and docs for the auth adapter. Maybe the issue has been fixed.