can github login token be used for calls to their api?

[vgrafe]

Hi everyone!

I am developing a GitHub OAuth app, and could use next-auth to create a session successfully. But without database, the session object does not expose any token string for later use. When a database is set up, the access token provided does not seem to allow authenticated api calls.
I am trying to use octokit but I think this problem applies regardless of the client library used; without a token I am not sure how to address this.

edit: I found this info but unfortunately am kinda lost by "persist them to the JSON Web Token".

[vitormv]

Yes its possible. Basically you do get the accessToken from Github (when using this provider), after the user is redirected. Unless you explicitly save that value to the token (or the session), it will be discarded. Here is an example:

import Providers from 'next-auth/providers';

const nextAuthOptions = {
  secret: process.env.NEXTAUTH_SECRET,
  jwt: {
    secret: process.env.NEXTAUTH_JWT_SECRET,
    encryption: true, // this is extremely important, because the Github accessToken is being stored inside the JWT.
  },
  providers: [
    Providers.GitHub({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET,
      scope: 'user repo', // add your own
    }),
  ],
  callbacks: {
    jwt: async (token, user, account, profile) => {
      // when user comes back after SignIn, we make sure to save the accessToken from
      // the logged user, otherwise it would be discarded. We need to make API calls to Github API
      // on behalf of the logged user, so here we persist the token, since its gonna be needed.
      if (user && account && account.provider === 'github') {
        token.username = profile.login; // save the github username
        token.githubAccessToken: account.accessToken, // get the github accessToken from the user who signed in
        token.randomStuff = 'anything you want';
      }

      return Promise.resolve(token);
    },
};

But if you do this, remember JWT IS NOT SECURE by default. Make sure that your JWT token is, at the very least, encrypted (as shown above).

[vgrafe]

This is perfect, thanks! I totally get it. I will give it a try within a couple of days. Danke shön!

[vgrafe]

This seems to be working (there's a couple of typos in your snippet but anyone coming here should figure it out easily), but now here's the follow up question: I was expecting getting the token through the session returned by useSession, but it does not seem to include the access token!

I found next-auth/jwt, is it what I am supposed to be using to decrypt the JWT token thus getting the session token? If so, it seems to be only usable on server side since it probably reads the token from the req parameter, required. Am I wrong and there's a way to decrypt the JWT in client-side, from the render method?

Again, thanks for helping on this!

edit - I found the following in the docs:

If you want to pass data such as an Access Token or User ID to the browser when using JSON Web Tokens, you can persist the data in the token when the jwt callback is called, then pass the data through to the browser in the session callback.

Thing is, the session's user object is not updated according to the cahnges made in the jwt callback. I had to override with the following:

    session: async (session, user) => {
      return Promise.resolve({ ...session, user });
    },

Is that correct to do?

[njordek]

Well, if you need to decrypt JWT client side, that means something is fundamentally wrong. The best you can do it READ/decrypt JWT token server side, and send the data already "parsed" to client side. The only way to actually decrypt it client side it to provide the secret keys used to encode it, and this is a MAJOR security risk. Basically you are giving your users the key that can open anyones JWT on your application, not only theirs, but everyone elses. I'm sure you don't want that :D

[vgrafe]

I had the feeling my first approach was not the right one. I ended up providing the token with the session so any decryption (and access to required info to decrypt) is done server-side. Now I wonder if my last remark (having to override the session callback) is due to a bug.