0

I have inherited an app that allows users to buy a gift card, and then see the gift card details after they have bought it. There are 4 main API calls - one to buy the gift card, one to get gift card details, one to attach a message to the gift card, one to get an images associated with the gift card.

Currently, the UI checks if there is a token in local storage and, if not, makes a call to /login. This is a anonymous login endpoint that returns a Json Web Token called an accessToken and a userId, which is a GUID. The token has this GUID baked into it, and expires in 60 days.

The structure of the API calls are:

/buy/{userId}/giftcard

/view/{userId}/giftcard/{giftcardKey}

etc

The 2nd call is protected with 2FA via SMS. Someone trying to steal the gift card details would need to giftcardKey and access to the phone associated with the gift card.

The accessToken is sent in the Header. The call is deemed to pass authentication if the userId in the URL is matched to the userId baked into the accessToken.

I have a few questions:

What are the advantages and flaws of this approach? Are JWT really necessary when users' don't actually have accounts? For example, I don't see what the point is to have this type of security for the buy gift card call.

A current problem is if a user comes back after 61 days, the API calls fails as the accessToken has expired - and they need to clear local storage for it to work. This is obviously unacceptable. What is a better approach?

EDIT: I just today discovered that the UI uses cache expiry TTL... when page refreshed, the UI get's data from localStorage and if it's 24h old, that means "cache miss" and "no data exists" and UI does /login again. So the above 61 day scenario wont happen....

Mark
  • 181
  • 1
  • 10

1 Answers1

1

What are the advantages and flaws of this approach? Are JWT really necessary when users' don't actually have accounts? For example, I don't see what the point is to have this type of security for the buy gift card call.

From what I can see, users do have accounts, although minimal. As in, there are users with IDs and gift cards are linked to them. What you described makes sense, /login authenticates and establishes a "session" of sorts.

Having this authentication before a buy allows you to bind the new gift card to the user who authenticated.

As for how this approach compares to others and what alternatives you have, take a look at the Web Authentication Guide.

A current problem is if a user comes back after 61 days, the API calls fails as the accessToken has expired - and they need to clear local storage for it to work. This is obviously unacceptable. What is a better approach?

This is the typical case of needing to keep alive an authenticated session. What you described is an implementation of this using JWT. This works but has its downfalls. More on session management here.

Daniel Szpisjak
  • 1,825
  • 10
  • 19