Inverted authorization mode - @Public() decorator

[breytex]

Original title: Running a guard before the middlewares

Hello :)
Usually, ppl in the GraphQL world use an @Authorized() guard to shield resolvers from unauthorized access. I want to build the opposite: a @Public() guard to flag a few resolvers as "available without login". Reason is, that my SaaS app has like 3 (login-related) mutations which are public, and all other resolvers are guarded with @Authorized() so far. I would like to turn this upside-down.

So I have a Public guard:

export function Public<T extends object>() {
    return UseMiddleware(async ({ args, context }, next: NextFn) => {
        console.log("public field")
        context.public = true   // default set in index.ts is false
        return next()
    })
}

and an auth middleware:

export class CookieAuthMiddleware implements MiddlewareInterface<MyContext> {
    async use({ context, info }: ResolverData<MyContext>, next: NextFn) {
        if (context.public) {
            console.log("public request, authorized")
            await next()

        } else {
              // do some cookie / session magic to check access rights
        }
     }
}

My main problem here is, that a middleware is executed before before the guards in type-graphql, which breaks the entire idea of my approach.
I want to detect if a request targets a public resolver using the guard and then "skip" the auth middleware. This requires the public guard to be executed before the middlewares.

Is it possible to make a guard execute before the middlewares in general?
Or do you see a different approach for implementing @Public() as a counterpart to @Authorized()?

[MichalLytek]

@breytex
This issue is partially related to #200.

But don't use context for placing metadata, especially the security-related 😱
Resolvers are executed in parallel, without maintaining the order.
So if you send a document with two queries (one public, one private), you may place the context.public = true first and then execute the private query resolver.

With this public approach of auth guards, you should wait for #124 to place arbitrary metadata on fields/resolvers and then just access it in your middlewares/guards.

In the meantime, as a temporary solution you can create an alias @Public() = @Authorized("PUBLIC") and in authChecker just do the inverse check 😞

[breytex]

Hey @19majkel94 , thanks for your quick answer :)
Will definitely subscribe to updates on #200 and #124.

Two questions regarding your suggestion:

• how to create a guard alias @Public() = @Authorized("PUBLIC")? Can't find any examples on that and also couldn't figure that out myself :(
• Consider I use the reverse check in @Authorized("PUBLIC"), how can I block access to all resolvers as default? Doesn't that loop-back to my opening question? @Authorized is a guard and "blocking all resolvers for not logged-in user" would require a middleware to run after the @Authorized guard, right?

[MichalLytek]

how to create a guard alias

const Public = () => Authorized("PUBLIC")

class SampleResolver {
  @Query()
  @Public()
  samplePublicQuery(): boolean {
    return true;
  }
}

how can I block access to all resolvers as default?

I think about making some changes in applyAuthChecker - I can pass null for the fields not annotated with @Authorized, so it would be easy to make the inverse check and would not harm so much other users but it's a breaking change so I have to think twice and group this feature in one new release.

[breytex]

I don't know if its worth it to introduce a breaking change like that just to save a few lines
(e.g. 20x @Authorized() vs 3x @Public() for my project).

I published my little test project for the sake of discussing, and pushed the unsecure state to a different branch:
https://github.com/breytex/typegraphql-typeorm-auth/tree/feature/public-guard-auth
It still uses the insecure context.public = true in the authChecker approach. I added a warning in the readme.

And you are right:

mutation{
  createTodo(text: "test") # not-public mutation
  requestSignIn(user:{email:"foo@test.de"})  # public mutation
}

results in accessDenied
while

mutation{
  requestSignIn(user:{email:"foo@test.de"})  # public mutation
  createTodo(text: "test") # not-public mutation
}

results in a success and broken records in the database (empty owner relations since no user is logged-in). Thanks for pointing me to that issue.

Relevant code excerpts:

• https://github.com/breytex/typegraphql-typeorm-auth/blob/feature/public-guard-auth/backend/src/middlewares/cookieAuth.ts
• https://github.com/breytex/typegraphql-typeorm-auth/blob/feature/public-guard-auth/backend/src/guards/authChecker.ts

Tried some stuff, but I don't see a quick fix here. Probably have to wait for the next major version before continuing this. Or I switch to using@Authorized() as it is intended to work :D
Or do you see a possibly working approach instead of using context?

[MichalLytek]

I don't know if its worth it to introduce a breaking change like that just to save a few lines

It's definitely worth, your use case is not so rarely.

I just have to think about a good API for it:

• @Public() decorator
• passing null to the authChecker for fields without roles (no @Authorized() decorator placed)
• maybe authCheckerMode or something, where you can define if fields by default are authorized or public

Or do you see a possibly working approach instead of using context?

The ideal and universal solution for custom rules will be #124 and middlewares 😉
The built-in authorization feature would be only a sample implementation of it.

[MWhite-22]

In this same vein, would it be possible to mark an entire resolver set as @public or @Authorized?

This way we can break our public resolvers into a separate resolver object that is all combined and buildSchema.

[Gallevy]

In this same vein, would it be possible to mark an entire resolver set as @public or @Authorized?

This way we can break our public resolvers into a separate resolver object that is all combined and buildSchema.

I like the idea of marking an entire resolver as @public or @Authorized
It gives much more room for separation of concerns