[Question] General auth strategy

[SachaG]

I'm sure I could answer my question with a close enough look at the code, but I'm not super familiar with GraphQL modules and other concepts employed by the codebase yet so I thought it might be quicker to just ask directly.

Basically, I'm wondering what auth strategy is employed by the app? I saw that it uses Passport, but does it use Passport's "normal" patterns and endpoints, or does the auth also go through the GraphQL layer? In other words, would signing up, logging in, etc. all be treated as GraphQL mutations? Or just requests to endpoints?

FWIW I've been asking around and most GraphQL apps seem to keep the auth layer separate from GraphQL, and it does seem like this is also what this app does, but I wanted to double check and maybe hear more about what lead you to adopt this approach.

[DAB0mB]

We use a basic token based auth strategy which is exported through a REST endpoint. The handlers themselves are not implemented inside GraphQL resolvers in anyway, but the result of the authentication aka current user will be accessible in the resolvers via context. What's nice about what we did is that we included the REST endpoint as part of a GraphQL module which can easily be imported and plugged to other modules in other applications, so it's completely agnostic. See auth module's source code. Hope this helps

[SachaG]

What's nice about what we did is that we included the REST endpoint as part of a GraphQL module which can easily be imported and plugged to other modules in other applications

I saw that, actually I didn't know you could do that with GraphQL modules! Seems like something I need to explore more. Thanks!

[DAB0mB]

Happy to help

[Urigo]

That is what we did, but in a lot of our apps we use js-accounts and making auth it own GraphQL Module.
We talked about it today and we will refactor the server to use that type of implementation.
I've re-opened the issue until we'll get a PR from @ardatan that we could discuss on and after that get @DAB0mB and @darkbasic reviews after making sure it's integrated with the React and Angular clients

[SachaG]

Oh interesting, js-accounts was the other thing I was looking at, precisely because it offers a better GraphQL integration. Looking forward to see what you end up doing!

[Urigo]

@SachaG you can check out the related PRs that @ardatan did here:
#64
Urigo/WhatsApp-Clone-Client-React#60

[SachaG]

Thanks! Can I ask what pushed you to use Accounts.js since you already had Passport working?

[SachaG]

Oh so you didn't use Accounts.js in the end?

[ardatan]

@SachaG But we're going to use it later.

[darkbasic]

@SachaG there are several reasons to prefer Accounts.js.
If you put the whole GraphQL endpoint behind the authentication middleware like we do with Passport you won't be able to make any query unless you're authenticated. You may want some queries to be accessible to unauthenticated users while keeping the others behind authentication. Think about introspection queries for example: with Passport if you want to generate typings with the graphql-code-generator you will have to either point it to the schema using a file path or provide it with the authentication header.
Also when you use GraphQL Modules you will have to use the middleware config to access the Express app and create the endpoint at load time: https://tortilla.academy/tutorial/whatsapp-angular/step/13
This is not so elegant and we would rather prefer not having to do so.
Accounts.js instead uses the GraphQL endpoint for authentication and thus solves all of these problems. The main disadvantage is that it is relatively mature compared to other solutions. Some enterprises could still prefer a more battle-tested solution which undergone multiple penetration testings, so we want to show both solutions despite preferring Accounts.js.