[Feature]: Google Authorization - Register method.

[Furman1331]

Package.json file

{
  "name": "pritty-prints-medusa",
  "version": "0.0.1",
  "description": "Pritty Prints Store CMS build with Medusa",
  "author": "Michał Furmańczak (michalfurmanczak@gmail.com)",
  "license": "MIT",
  "keywords": [
    "sqlite",
    "postgres",
    "typescript",
    "ecommerce",
    "headless",
    "medusa"
  ],
  "scripts": {
    "build": "medusa build",
    "seed": "medusa exec ./src/scripts/seed.ts",
    "start": "medusa start",
    "dev": "medusa develop",
    "test:integration:http": "TEST_TYPE=integration:http NODE_OPTIONS=--experimental-vm-modules jest --silent=false --runInBand --forceExit",
    "test:integration:modules": "TEST_TYPE=integration:modules NODE_OPTIONS=--experimental-vm-modules jest --silent --runInBand --forceExit",
    "test:unit": "TEST_TYPE=unit NODE_OPTIONS=--experimental-vm-modules jest --silent --runInBand --forceExit"
  },
  "dependencies": {
    "@medusajs/admin-sdk": "^2.0.3",
    "@medusajs/cli": "^2.0.3",
    "@medusajs/framework": "^2.0.3",
    "@medusajs/medusa": "^2.0.3",
    "@mikro-orm/core": "5.9.7",
    "@mikro-orm/knex": "5.9.7",
    "@mikro-orm/migrations": "5.9.7",
    "@mikro-orm/postgresql": "5.9.7",
    "awilix": "^8.0.1",
    "pg": "^8.13.0"
  },
  "devDependencies": {
    "@medusajs/test-utils": "latest",
    "@mikro-orm/cli": "5.9.7",
    "@swc/core": "1.5.7",
    "@swc/jest": "^0.2.36",
    "@types/jest": "^29.5.13",
    "@types/node": "^20.0.0",
    "@types/react": "^18.3.2",
    "@types/react-dom": "^18.2.25",
    "jest": "^29.7.0",
    "prop-types": "^15.8.1",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "ts-node": "^10.9.2",
    "typescript": "^5.6.2",
    "vite": "^5.2.11"
  },
  "engines": {
    "node": ">=20"
  }
}

Node.js version

v20.5.1

Database and its version

Postgres

Operating system name and version

MacOS

Browser name

Brave

What happended?

Google Authorization Provider does not support method "register", right now to create an account throught Google Provider we send callback method to check is user exist in database. If does not we need to create user by "api/store/customers". But before that we need to collect e-mail address from user by form.

To stay convenient I suggest to add support for register method, which right now is empty.

I'm curious why it was not done from the beginning, are there any contraindications?

Just want to make sure that I can a upload PR for that feature without wasting time.

Expected behavior

Register method does create user in database and authorize. Make it convenient

Actual behavior

Google Provider register method does not support.

Link to reproduction repo

...

[Furman1331]

@sradevski, I ping you because, saw that you've done this provider.

[sradevski]

@Furman1331 both registration and authentication happens through the authenticate method for Oauth providers, register is only for auth methods such as email/password. Here are the docs: https://docs.medusajs.com/resources/commerce-modules/auth/auth-providers/google#main

[Furman1331]

Yeah, I read the docs and checking the code, but it's non sense to make user fill form with e-mail when we've got it from google provider. We can use register method to make it more smooth and convenient, like i said above.

In Google OAuth we can get the data from google more then once, so in register method we can get email and register customer / user in database without filling the form, and automate this process.

This is, after all, why we are implementing, such solutions.

[sradevski]

I think the only missing piece is not storing the email in the user metadata here: https://github.com/medusajs/medusa/blob/9e40f34ba8ffb70c25fdc8a485afaa2f215eae96/packages/modules/providers/auth-google/src/services/google.ts#L146C11-L146C23

You can then use the user metadata to pre-populate whatever you need from the auth provider.

[Furman1331]

Yeah but what we can do with this e-mail stored in provider-identity? To create new customer we need to pass e-mail address in request, if we add such an email to the metadata, it will do us no good unless we return it to the frontend, which in turn may cause a security vulnerability

Right now example decoded token from response is: actor_id: "" actor_type: "customer" app_metadata: {} auth_identity_id: "authid_00000000" exp: 1731505363 iat: 1731418963

Look on image bellow, how it could look.

[sradevski]

The user_metadata on the provider identity doesn't carry anything sensitive, so it can be returned to the FE if needed.

If you were to eg. create a customer in the register method, then you are mixing two separate concerns - authentication vs. application roles, and there can be many, depending on the application.

If you need the provider identities, you can create an endpoint to get them in your app so you can prepopulate some email field you have

[SalahAdDin]

Yeah but what we can do with this e-mail stored in provider-identity? To create new customer we need to pass e-mail address in request, if we add such an email to the metadata, it will do us no good unless we return it to the frontend, which in turn may cause a security vulnerability

Right now example decoded token from response is: actor_id: "" actor_type: "customer" app_metadata: {} auth_identity_id: "authid_00000000" exp: 1731505363 iat: 1731418963

Look on image bellow, how it could look.

how did you create such image? looks awesome!

[Furman1331]

Yeah but what we can do with this e-mail stored in provider-identity? To create new customer we need to pass e-mail address in request, if we add such an email to the metadata, it will do us no good unless we return it to the frontend, which in turn may cause a security vulnerability Right now example decoded token from response is: actor_id: "" actor_type: "customer" app_metadata: {} auth_identity_id: "authid_00000000" exp: 1731505363 iat: 1731418963 Look on image bellow, how it could look.

how did you create such image? looks awesome!

You mean the screenshot, I have just add some text?