OIDC/Oauth2 improved implementation

Hello thanks for building and supporting this awesome piece of software 🤗

I've being poking with this DB to build a POC and deploy it to prod. Any prod deploy MUST ensure a protected API protection, where OIDC/Oauth2 is a de-facto standard today.

However, as of DGraph v24.0.5 I built a protected schema, but was able to drop my database with an unprotected call 🤦

Here's my protected schema as per your docs:

type Person {
  id: ID!
  xid: String! @id
  name: String!
  age: Int @search
  friends: [Person] @hasInverse(field: "friends")
  ownsPets: [Animal] @hasInverse(field: "owner")
}

type Animal {
  id: ID!
  xid: String! @id
  name: String!
  owner: Person @hasInverse(field: "ownsPets")
}
# Dgraph.Authorization {"header":"X-Dgraph-AuthToken","namespace":"https://dgraph.io/jwt/claims","jwkurl":"https://my-corp.com/.well-known/jwks.json","audience":["mycorp","dgraph"],"closedbydefault":true}

And I've been able to drop all with the following call:

describe('DGraph drop data', async () => {
  it('drop data', async () => {
    await client.alter({ dropAll: true })
  })
})

Would you accept a PR which

1. Protects API on the request level ?
2. Deploys a thin 3-d party wrapper around the golang-jwt/v5 lib ?

Thanks in advance and thanks for DGraph again 😄

Environment:
OS: Ubuntu 24.04
Dgraph: v24.0.5
Kubernetes: 1.32.0
dgraph-js-http: 23.0.0-rc1

Start by reproducing the unprotected client.alter({ dropAll: true }) request against the protected schema described in the issue and review the linked Dgraph authorization documentation. Investigate the request-level API protection boundary and the proposed golang-jwt/v5 wrapper. Done means destructive requests are protected without weakening the documented OIDC/OAuth2 behavior, with validation covering the reported case.