I understand that Oauth can be used as an authorization protocol. After the user is authorized, I would like to enable authorization with role-based access control (RBAC). For instance, defining an administrator to my application, or various other roles.

For the context, I am using NextAuth and GitHub as the Oauth provider.

My configuration is basic:

import { NextAuthOptions } from "next-auth";
import GitHubProvider from "next-auth/providers/github";

export const nextAuthConfig = {
  providers: [
    GitHubProvider({
      clientId: process.env.GITHUB_ID!,
      clientSecret: process.env.GITHUB_SECRET!,
    }),
  ],
} satisfies NextAuthOptions;

When authenticating users, I receive their emails. From there, how am I supposed to assess their role, with respect to the Oauth protocol?

My initial idea is to get the role in a database based on the email. Then I need to store this role wherever relevant, so probably either in the user session in the database (let's say role won't change often to simplify the problem) or in a JWT.

How should I attribute a role to the user after a successful authentication?

I understand that Oauth can be used as an authorization protocol. After the user is authorized, I would like to enable authorization with role-based access control (RBAC). For instance, defining an administrator to my application, or various other roles.

For the context, I am using NextAuth and GitHub as the Oauth provider.

My configuration is basic:

import { NextAuthOptions } from "next-auth";
import GitHubProvider from "next-auth/providers/github";

export const nextAuthConfig = {
  providers: [
    GitHubProvider({
      clientId: process.env.GITHUB_ID!,
      clientSecret: process.env.GITHUB_SECRET!,
    }),
  ],
} satisfies NextAuthOptions;

When authenticating users, I receive their emails. From there, how am I supposed to assess their role, with respect to the Oauth protocol?

My initial idea is to get the role in a database based on the email. Then I need to store this role wherever relevant, so probably either in the user session in the database (let's say role won't change often to simplify the problem) or in a JWT.

How should I attribute a role to the user after a successful authentication?

• authentication
• next.js
• oauth-2.0
• authorization
• rbac

Share Improve this question Follow asked Mar 13 at 16:09 Eric BurelEric Burel 5,00666 gold badges4242 silver badges6767 bronze badges

Add a comment  | 

1 Answer 1

Sorted by: Reset to default 1

A more complete OAuth flow works like this:

• Your Next app redirects to your authorization server (AS) where you store user accounts and any custom fields like roles.

• The AS can use various login methods including identity providers (IDP) like GitHub. It can then use values returned from the IDP (like the email) to identify the user account, then issue any user account values to tokens returned to your app.

If you don't yet have that type of setup you can instead use a pattern where you build a custom claims object that includes user attributes from two sources, the GitHub ID token and your own database:

interface Claims {
   idTokenClaims: any:
   customClaims: any;
}

In NextAuth you can override the jwt callback, do a database lookup and update the token object with extra properties. Note that this does not really change the token itself.

CLAIMS

True claims are those asserted by an identity system and delivered in a verifiable token. However, it is common to combine token data with additional values when implementing authorization.

Larger setups would send access tokens to APIs, which can use similar techniques to manage their authorization.

STANDARDS

RFC9068 discusses how an access token contains scopes and each scope can contain claims. The authorization server issues custom claims like roles, groups or whatever else you want to put in access tokens with a particular scope.

This doesn't mean that you add every possible authorization value to tokens though. Eg add a role but if a role has many fine grained permissions, derive them from the role in the token.

IDPs don't allow you to design scopes and claims in custom ways though. Since scopes and claims enable authorization, issuing them is the responsibility of the authorization server.