{"id":14854,"date":"2022-02-21T12:03:42","date_gmt":"2022-02-21T11:03:42","guid":{"rendered":"https:\/\/www.centigrade.de\/?post_type=blog&p=14854"},"modified":"2022-02-24T14:08:45","modified_gmt":"2022-02-24T13:08:45","slug":"how-to-engage-graphql-net-and-react-together-part-ii-veda-versum-backend-authentication","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/en\/blog\/how-to-engage-graphql-net-and-react-together-part-ii-veda-versum-backend-authentication\/","title":{"rendered":"How to engage GraphQL, .Net and React together: Part II. Veda Versum backend authentication."},"content":{"rendered":"
\r\n

 <\/p>\r\n

“If you optimize everything, <\/em>you will always be unhappy” – \u00a0<\/em>Donald Knuth<\/a><\/p>\r\n<\/blockquote>\r\n

Having a good tool allows you to complete tasks effectively and enjoy the process. Twice the fun to develop the tool yourself \ud83d\ude42<\/p>\r\n

Hi, It\u2019s Mikhail<\/a> from Centigrade again. And let\u2019s continue to build our tool – knowledge base called Veda Versum<\/strong>. This is my second article in the series \u201cHow to engage GraphQL, .Net and React together\u201d. In the Previous article<\/a> we have defined our target application, requirements and architecture. We have also chosen the .Net 6 for backend with hot chocolate<\/a> library for GraphQL<\/a> API and React<\/a> as the UI framework. And we have created the backend application scaffold<\/a>. Now it\u2019s time to give life to our backend.<\/p>\r\n

Today we will add Authentication to backend. We will define and implement the data persistence for our application. We will talk about GraphQL resolvers<\/em> and data loaders<\/em> and will say a couple of words about testing.<\/p>\r\n

Let\u2019s get it started! \ud83d\ude09<\/p>\r\n

1.\u00a0\u00a0 Authentication and Authorization<\/h2>\r\n

We have already discussed in the previous article that each user can open application, create some knowledge cards, read cards and see other users who are being online. Sure, our Veda Versum<\/strong> application is supposed to know each user personally :-). As you already know, the common way to \u201cshow yourself\u201d in the IT world is \u00a0to log into<\/strong> the system. Yep, to do this you should have an account with login and password. Nothing new. We have to provide the same functionality for our brand new application. But we will not reinvent the wheel and will not implement the process of keeping users credentials by our own. We will use the standard protocol called OAuth 2<\/a>. According to this standard we are assumed to use already existing authentication server for our users. A lot of providers like Microsoft, Google, Twitter, Facebook and others support this protocol. So if you want to implement your own user management but don\u2019t want to run your own authentication server, you can use those. And one significant player in the field is Auth0<\/a> which specializes on authentication services. But as far as our team uses GitLab for most of our projects, all of us have an account in GitLab. Therefore GitLab.com will be our OAuth provider. So Veda Versum<\/strong> user doesn\u2019t have to create one more account to login in Veda Versum<\/strong>, he or she can use already existing account in GitLab. Our application will redirect user to GitLab login page and after user enters his\/her login and password, he or she will be redirected back to our application but with some authentication token. And our application will operate only with this token.<\/p>\r\n

As far as our application has Frontend, Backend, and GitLab as OAuth 2 provider, authentication schema will look like this:<\/p>\r\n

\"Authentication

Fig. 1: Authentication scheme<\/p><\/div>\r\n

The whole scheme looks a bit complicated. I will try to explain all the details and guide you through all processes step by step.<\/p>\r\n

1.1 GitLab Authentication mutation<\/h3>\r\n

First and foremost, we have to set up OAuth in the GitLab settings page. Follow these instructions to create Group Owned Application.<\/a> As a result we will have Application Id<\/em><\/strong> and a secret<\/em><\/strong>. We will need them for next steps.<\/p>\r\n

This is the link to Gitlab OAuth API<\/a> to implement the authentication. To implement steps 2 and 4 from Figure 1<\/strong> we need to call oauth\/authorize<\/u><\/strong> GitLab API method. This method will be called from UI. Later to implement steps 6 and 7 we must call method oauth\/token<\/u><\/strong>. And for steps 8 and 9 \u2013 to call method \/api\/v4\/user<\/u><\/strong>.<\/p>\r\n

Frontend is not our goal for today, here we will focus on the backend part<\/strong>. To implement steps from 5 to 10 from Figure 1<\/strong> we must create a brand-new mutation in our GraphQL API which should retrieve GiltLabUser information. It will take GitLab single-use Auth Code<\/u> as a parameter and return secured JWT token containing the user information. This mutation will incapsulate the implementation of steps 6 – 9 from Figure 1<\/strong>.<\/p>\r\n

To do that we have to change our project this way:<\/p>\r\n