Web Application + API

Help
,
1

I am mostly curious about whether I’m thinking this through in the right way, because I’ve had some trouble understanding Auth0’s primitives and their intended use (applications, APIs, etc).

In my service, users can log in as themselves or as a member of an organization, and can only access organization data when logged in as a member of that organization (likewise, can only access personal data when logged in not as an organization member).

I have two components:

  • A Next.js application
  • An API written in Go

Generally, a user logs into the Next.js application, which makes requests to the API for data (only on the server, never from the client—so everything is stored in httpOnly cookies). The Go API will need to do things like ensure that a user is a member of a given organization and ensure that the current access token is scoped to the given organization the user is requesting resources from.

This seems to require three things:

  • A Next.js web app Auth0 Application
  • A Go API Auth0 API (this is the audience of the Next.js app’s login flow)
  • A Go API Auth0 Application (so that the Go API can request data from the Auth0 management API, using the client credentials grant type, presumably)

However, this leaves a few unanswered questions:

  • How does the Go API verify that a given access token should be scoped to a specific organization? This doesn’t appear to be in the claims passed in the access token—only the ID token, which the Next.js Auth0 client doesn’t make available, as far as I can tell (I’m using @auth0/nextjs-auth0@4.0.0-beta.3).
  • Manually checking organization membership via the API for every request to organization data seems really slow. With a non-SaaS identity solution, this would normally require database calls or fast checks within the same DC between service. With Auth0, there doesn’t even appear to be a single API call that allows me to just check organization membership for a given user—I have to list user organizations and paginate through all of them (granted, it’s unlikely that one of my users would have >50 organization memberships, but still).

Anyway, hope this isn’t too vague! Otherwise the product is nice, so far.

2

I have noticed that the org_id is actually in the access tokens claims, so that’s good. This may partially solve my problem (the issue of immediate revocation on org membership removal aside, which would still require slow API calls)—I’d still like to understand whether my general approach is valid, though.