Sessions & Cookies or JWT tokens for authentication.

[DNature]

I came across few mutation arguments that are supposed to be signed and unique. It can be faked or break the application when a wrong ID is provided.

Users are not expected to provide their I'd because it's unique and they don't know it neither do they need to know it.

We can fix this by implementing sessions or cookies.

When a user is signed in(authenticated) he'll be issued a JWT token or A cookie with a session ID that will be used to authorized to perform some actions like commenting, creating a post, ... and their ID will be extracted on the server from the token or cookie provided by the user when they are signed in.

type Mutation {
    addPost(title: String!, imageUrl: String!, categories: [String]!, description: String!, creatorId: ID!): Post!
  }

The above mutation contains creatorId: ID! field and it's not supposed to be provided manually by the user.

[raahul1912]

@DNature yes we will store that information in JWT.

[DNature]

Cool. I'll implement that ASAP. Ive made a lot of changes on this project and I'll make a PR as soon as I'm added as a collaborator

[DNature]

@raahul1912, @jurra We know this projects code base is gonna grow with time. To get things done with need to keep it simple and take things one step at a time. The first step is to handle basic authentication and authorization

• signup
• signin
• signout
• cookies/tokens
• ...etc.

Splitting things up: The signup action a little bit we are gonna have the following fields:

• username
• email
• password and we are also going to authenticate users email by sending a confirm email link to their mailbox later on and nodemailer would be a fantastic service for testing.

The signin is just going to require a username or email and a password then return either a cookie or a JWT token which will be stored in the browser.

The signout action will invalidate the users session in the server and clear their token or cookie.

Before a user can create a design he/she needs to be logged in then other checks will be made and our code can now extract values like (id, email, etc) from the users browser storage and use it where necessary.

Feel free to correct me if i'm wrong. :)

[DNature]

Let's resolve this issue guys. What are we gonna be using to handle authentications? Cookies or JWT.

JWT is much easier to setup. However, it's less secure compared to Cookies because cookies may require a middleware to make it work efficiently. i.e express-session, redis for caching sessions, etc.

[raahul1912]

I and @jurra had a talk about Authentication and Authorization. For this project we will gonna be use OAuth of GitHub. So, we will do all signup, signin things by GitHub.

And for Authentication I think JWT is good idea. For mailing we can use Nodemailer.

@narration-sd have a look on this and suggest if something is missing.

[narration-sd]

hello guys -- I'll have a better look after some very good and productive work with @jurra tonight -- things for early content to show. It's 0230 here...

I'll say a little here, and then it's looking like over the weekend or as we can discuss. For reference, just Google thinks I'm 13hrs earlier in the day than Ahmedabad, and 8 hours earlier in same day than Lagos, though I don't know if that's where you are, @DNature.

Security is a demanding game, isn't it, when you know about it.

• I am thinking that when you mention OAuth, you are thinking of how you would connect your app to GitHub.
• on the front of it, I may see two uses as possibilites, if not sure yet what you plan...
  • for someone needing to search and download content, I'm not seeing a need for login, and in fact that would be counter to our project purpose, which is to get designs available and into hands that can understand and get them produced for needs we know about.
  • So that should be frictionless as possible, no? Like using Google. And what they receive is by intent and purpose Open Source, made as easy as possible. -We'll have more to , talk about, in how simple and robust in difficult conditions this needs to be, but on the first surface I think you can see it shouldn't have authentication, and authorization is automatic: they are permitted to discover, see, and download the content.
  • this leaves us with the other face of the application I may understand, if it's true, which is somehow to allow outside persons to upload content, designs. This is what needs to be firewalled, as it's where either mistakes or bad intent could damage CombatCovid. You'll understand better than many that what seems help to some is not met with approval or pleasure by some others, and while that's a very interesting problem I think we can work on, for security we can only start with having best door strength and safe places

So with this as a framing, I should tell you that I was just looking at JWT for another purpose, and found I was very happy to use other available methods instead. It's clear that effectively using it for real security is as ever, very challenging -- experts discuss. The best way I saw combined cookies and tokens in a very precise handshake to gain something like actual security.

• My suggestion then is that you look into using OAuth also for the content-uploader door. This is a very established technology, that dependably works, and with all the severe difficulties handled inside groups like Google and Github.

• In fact, let's consider that the received content is going on to GitHub -- so it's quite possible that some variation on their own OAuth you use already may be available to plug into for ab uploader system if there is to be one -- really a Single Sign On...just as a lot of serious web apps let you use your Google identity to log in, and not anything like asking for your Google password, I hope is clear.

I hope that gives a good entry into a path, for us to understand a way we'd like to frame this. Again, it's very late here, so I may be missing something of what you're thinking already. For one example, I'm not yet seeing that even the uploaders seem to need to go through our app -- why shouldn't they go directly to Github and put their materiel up, in a usual way? Then we only have to concern about the security vetting of what's in it, rather than who they are.

Ok, enough for me :) Take care, both, and let me know your thoughts.

Best, Clive