0

I have an Asp.Net Core 6 GraphQL API app. Server setup with Hot Chocolate and endpoints are served at localhost/graphql. When a user logs in GraphQL resolver generates both - access and refresh tokens, and sends in response as HttpOnly cookies. An access token cookie has a path - "/", and a refresh token cookie has a path - "/graphql/refreshtoken". The idea is that the browser in every request should send an access token, but a refresh token must be sent only when a client hits "/graphql/refreshtoken" endpoint.

I could not find any example with my scenario. And those that I found store refresh tokens in local storage, but not the cookie.

How can I setup the GraphQL server to serve /graphql/refreshtoken endpoint? Note: I don't want to additionally use REST for refresh tokens.

If the above approach is not achievable, how can I refresh cookie-stored tokens with GraphQL? What is the best practice?

enter image description here

Elshad Shabanov
  • 483
  • 10
  • 17
  • Imo you should reconsider your authentication scheme. Cookies are fundamentally linked to HTTP. GraphQL just happens to use HTTP as a transport, but should be agnostic of any HTTP-specific features. You should decide on one of two options: Either embrace GraphQL fully and make it handle your authentication. In that case create mutations for obtaining, refreshing and invalidating tokens. Otherwise, separate your application from authentication and e.g. implement an OpenID-like solution. – paolo Dec 29 '22 at 15:16
  • I can handle tokens by myself storing them in local storage. But that is considered a bad practice. But when I use cookies, then I am bound to HTTP specifications and should consider the browser's behavior. I don't mind an alternative solution as long as my tokens are stored in HTTP-only cookies, with GraphQL on the backend. But I couldn't find any example or a glimpse of the idea of how it should work in theory – Elshad Shabanov Dec 29 '22 at 15:57

0 Answers0