Yes. You will receive the token on authentication not autorization, then you will use the token to authorize actions.
Since it is a Strapi token it does not make sense to use the token directly with the provider, Strapi must validate the action using its own logic. If you want you can apply your own logic by customizing the JWT validation function.
One more thing: you may be confused when referring to the provider. What Strapi uses is a library that generates that token, not an authentication service provider such as OpenID Connect type ones like Login with Google, Login with Facebook and so on.
@SorinGFS thanks again. Yes I wanted to keep all server type actions on my strapi API server because my frontend will be served by a CDN.
I need to interact with a provider in ways that strapi doesn’t provide (like tweeting on behalf of users and liking posts). This will be carried out on the server.
I need a basic form of user sign in into my app frontend but all this will be is to validate that the user has a social media account. I won’t expose the token to the frontend but I will generate a user id that is associated with it.
It seems like I may have to write my own plugin to do what I want.
All I need is to store the provider name, auth token, username, email, and a uid that the frontend uses to direct the server to carry out some operations using the provider.
@strappinandgo, thanks for the info.
I am in the exact situation. can you please elaborate a bit on how did you manage to solve it?
I can see the ctx.state.user… but where and how exactly should I get/store refresh_token /accsess_token of the provider (Microsoft in my case) in order to interact on behalf of the user who grants permissions?
I wrote a hook into the users and permissions providers process. A function that is called just after the provider hands access token details back to the plugin.
It grabs this, the users email and username registered with the provider and stores it in an extended version of the user collection in strapi.
It works very well because I can now query the user and get all tge info necessary to carry out provider specific operations.
I then create my own JWT token that contains the username, and some other info like the users cart (I’m making an ecommerce app).
The payload is AES encrypted and then stored on the users browser as a http only cookie.
To retrieve the data in this cookie, the frontend calls a modified /users/me that first verifies that the token is valid against what is stored in my strapi db, before sending the decrypted data to the frontend app.
This is probably (definitely) overkill especially because I’m not exposing user’s provider acess token details to the frontend and because I’m using http only cookies, but I wanted to test this could work as a POC.