1

I am curious about using the UserTokens table, which is a part of ASP.NET Identity model, to store the refresh tokens.

A bit more context: I am developing a pretty trivial web API with the JWT bearer authentication. So I don't need to store authentication tokens in the database, unlike the refresh tokens. This article says that the UserTokens table is intended to store the authentication tokens, but since I don't need them in the database this table is just chilling around without any job.

So the question is: how suitable the UserTokens table is for storing refresh tokens in terms of good quality code, semantics accuracy and maintainability?

Arthur Edgarov
  • 473
  • 5
  • 16

1 Answers1

0

I believe you are mixing a few scenarios here.

  1. API is an Identity provider, capable to authorize user and generate refresh/bearer token

  2. API is an identity data consumer, ie consume token and validate it, and provide access to endpoints if token is fine.

In first case, you may need refresh tokens and obviously storage for them. In later this is useless.

On a separate note, API may want to cache validated tokens and store them for short period, since process of validation may require https calls to 3rd party Identity provider (check certificate etc).

The short answer no you most likely do not need it, unless you are not building Identity provider.

As for maintainability of default ASP. Net solution, I would highly recommend using ready to go OOB designs like this one https://github.com/topics/oauth2-server?l=c%23 or similar. Default ASP.Net implementation require to lot of tuning and effort for production ready quality

EDIT 1: Also note on this tread Why Does OAuth v2 Have Both Access and Refresh Tokens? with a good explanation of refresh tokens live-cycle.

Maksym
  • 820
  • 1
  • 8