Medusa plugins - Linkedin

Configuration

In order to be able to use the linkedin authentication provider, you have to add the configuration to your newly added plugins. To do so here are the steps

Configure your linkedin developer console

Go to your medusa-config.js

Check that the variables are set with the appropriate values

const BACKEND_URL = process.env.BACKEND_URL || "localhost:9000"
const ADMIN_URL = process.env.ADMIN_URL || "localhost:7000"
const STORE_URL = process.env.STORE_URL || "localhost:8000"
 
const LinkedinClientId = process.env.LINKEDIN_CLIENT_ID || ""
const LinkedinClientSecret = process.env.LINKEDIN_CLIENT_SECRET || ""

Then in your plugins collections, if you did not already inserted the plugin, add the following otherwise, you can just add the linkedin options to your auth plugin options

{
    resolve: "medusa-plugin-auth",
    /** @type {import('medusa-plugin-auth').AuthOptions} */
    options: {
        // strict: "all", // or "none" or "store" or "admin"
        linkedin: {
            clientID: LinkedinClientId,
            clientSecret: LinkedinClientSecret,
 
            admin: {
                callbackUrl:`${BACKEND_URL}/admin/auth/linkedin/cb`,
                failureRedirect: `${ADMIN_URL}/login`,
 
				// The success redirect can be overriden from the client by adding a query param `?redirectTo=your_url` to the auth url
				// This query param will have the priority over this configuration
                successRedirect: `${ADMIN_URL}/`,
 
                // authPath: '/admin/auth/linkedin',
                // authCallbackPath: '/admin/auth/linkedin/cb',
                // expiresIn: 24 * 60 * 60 * 1000,
                // verifyCallback: (container, req, accessToken, refreshToken, profile, strict) => {
                //    // implement your custom verify callback here if you need it
                // }
            },
 
            store: {
                callbackUrl:`${BACKEND_URL}/store/auth/linkedin/cb`,
                failureRedirect: `${STORE_URL}/login`,
 
				// The success redirect can be overriden from the client by adding a query param `?redirectTo=your_url` to the auth url
				// This query param will have the priority over this configuration
                successRedirect: `${STORE_URL}/`,
 
                // authPath: '/store/auth/linkedin',
                // authCallbackPath: '/store/auth/linkedin/cb',
                // expiresIn: 24 * 60 * 60 * 1000,
                // verifyCallback: (container, req, accessToken, refreshToken, profile, strict) => {
                //    // implement your custom verify callback here if you need it
                // }
            }
        }
    }
}

The options that are commented are optional and the value that you see are the default values

Update your client to add the authentication action

<a href="${medusa_url}/${authPath}" type="button" class="text-white bg-[#2663eb] hover:bg-[#2663eb]/90 focus:ring-4 focus:outline-none focus:ring-[#2663eb]/50 font-medium rounded-lg text-sm px-5 py-2.5 text-center inline-flex items-center dark:focus:ring-[#2663eb]/55 mr-2 mb-2">
  <svg class="mr-2 -ml-1 w-4 h-4" aria-hidden="true" focusable="false" data-prefix="fab" data-icon="linkedin" role="img" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256"><path fill="currentColor" d="M218.123122,218.127392 L180.191928,218.127392 L180.191928,158.724263 C180.191928,144.559023 179.939053,126.323993 160.463756,126.323993 C140.707926,126.323993 137.685284,141.757585 137.685284,157.692986 L137.685284,218.123441 L99.7540894,218.123441 L99.7540894,95.9665207 L136.168036,95.9665207 L136.168036,112.660562 L136.677736,112.660562 C144.102746,99.9650027 157.908637,92.3824528 172.605689,92.9280076 C211.050535,92.9280076 218.138927,118.216023 218.138927,151.114151 L218.123122,218.127392 Z M56.9550587,79.2685282 C44.7981969,79.2707099 34.9413443,69.4171797 34.9391618,57.260052 C34.93698,45.1029244 44.7902948,35.2458562 56.9471566,35.2436736 C69.1040185,35.2414916 78.9608713,45.0950217 78.963054,57.2521493 C78.9641017,63.090208 76.6459976,68.6895714 72.5186979,72.8184433 C68.3913982,76.9473153 62.7929898,79.26748 56.9550587,79.2685282 M75.9206558,218.127392 L37.94995,218.127392 L37.94995,95.9665207 L75.9206558,95.9665207 L75.9206558,218.127392 Z M237.033403,0.0182577091 L18.8895249,0.0182577091 C8.57959469,-0.0980923971 0.124827038,8.16056231 -0.001,18.4706066 L-0.001,237.524091 C0.120519052,247.839103 8.57460631,256.105934 18.8895249,255.9977 L237.033403,255.9977 C247.368728,256.125818 255.855922,247.859464 255.999,237.524091 L255.999,18.4548016 C255.851624,8.12438979 247.363742,-0.133792868 237.033403,0.000790807055"></path></svg>
  Sign in with Linkedin
</a>

medusa_url correspond to your backend server url (e.g http://localhost:9000)
authPath correspond to authPath configuration in your plugin (e.g admin/auth/linkedin)

After authentication is successfull, the user will be redirected to the successRedirect url with a ?access_token=your_token query param and a session cookie will be set. Session will automatically be authenticated. The access token is a JWT that can be used with Authorization: Bearer <token> header to authenticate requests to the backend instead of using a session cookie.

Default behaviour

The default verifyCallback flow looks as follow (unless the strict option is changed to none or store or admin depending on the targeted domain)

for the admin
- if the user trying to authenticate exists
  - then we are looking in the metadata to find if the strategy identifier is present in authProvider.
    - If it is not, the user authentication gets rejected.
    - In the case it is present, then the user authentication gets authorized.
- if the user trying to authenticate does not exist, an unauthorized error will be returned
for the store
- if the customer trying to authenticate exists
  - then we are looking in the metadata to find if the strategy identifier is present in authProvider.
    - If none are found, then the customer gets authenticated and can proceed and the metadata gets updated.
    - In the case another external authentication method have been used in the past, then an unauthorized will be returned.
- if the customer trying to authenticate does not exist, a new customer will be created with a randomly generated password and the authentication flow follow the previous point

Request only access token in a JSON response

If you are using your Medusa application with a SPA or mobile frontend, you can request opt to receive the access token in a JSON response instead of a redirect.

To do this, you have to add ?returnAccessToken=true query parameter to your authentication call. Your authentication URL will then look like this: ${medusa_url}/${authPath}?returnAccessToken=true

The response will look like this:

{
    access_token: "<your-jwt-token>"
}

Facebook Auth0