I have a NodeJS application where I let my users to login via an external auth like Github and Google.

In the frontend I open for the client a tab in Github for example which prompts him to authorize GitHub against my application. I also do this with a callback url. Github then redirects the user back to the callback url I've configured.

Currently this callback URL is an API in my server. The next step is to redirect the user back to my home page. However, I need to provide the user with some credentials like JWT token.

But I'm limited to send some data along with redirection action. What should I do?

I provide the following data with Github:

        super({
            clientID: configService.get('githubOAuthClientId', { infer: true }),
            clientSecret: configService.get('githubOAuthClientSecret', { infer: true }),
            callbackURL: configService.get('githubOAuthRedirectUri', { infer: true }),
            scope: ['user:email'],
        });

The githubOAuthRedirectUri variable holds my backend api route. Then I handle the data I receive from GitHub in this route controller. Now I want to redirect the user back to the home page but he also needs the JWT token and some more user specific data.

CodePudding user response：

After receiving data from Github, you could redirect to an intermediate page, sending data in url query for example, and then the front-end app redirect to the home page. That's my idea

CodePudding user response：

I assume that the OAuth provider (Google or GitHub) will invoke your callback URL with an authorization code in a URL parameter ?code=.... Your server must then exchange this authorization code for an access token by making a token request to the OAuth provider. The response to that token request will then contain the access token, which is

• either a JWT with a sub claim containing (most likely) the user's email address, see https://stackoverflow.com/a/72590693/16462950
• or an "opaque" token, which your server must use in an Authorization: Bearer header of a UserInfo request.

Only after these steps do you know who the user is. Your server could put the JWT in a session cookie so that it is sent again (and must be validated again) in all subsequent requests.

If your server receives an opaque token instead of a JWT, this may be only short-lived and hence cannot be used in a session cookie. In this case, your server could construct its own JWT containing the user info.