CODEWITHSUNDEEP
gooauthserveroauth-2.0access-token
levye
levye

Reputation: 195

OAuth 2 and managing multiple user access tokens for server side

I have a server-side app (implemented in GO) which fetches user data from an external API. (user data is stored by a 3rd party companies and they provide API to access it.) I have actually two types of users. One of them is patients and other is a doctor. Doctor actor here is responsible for monitoring patient data. So the flow is,

  1. Patients (1..n) authorize the server-side application using OAuth2 grant access token flow.
  2. Server regularly fetch patient data via API and stores patient data on a local DB
  3. The doctor can check any patient data any time which has been stored on local DB

Step 1 is easy. Implementing OAuth2 grant flow, I can get access_token and refresh_token for each user. Let's say I have 100 patients. I am assuming that I can obtain up-to-date access_token using refresh_token without patient interaction again.

Question is, After patient authorized the app, I need to store his/her access_token and refresh_token somewhere so that whenever server starts a scheduled job to fetch patient data, then the server can access external API using a valid token. What is the general approach here? Should I store access_token and refresh_token on my user table and use them whenever needed?

Since I have n patients (n tokens) and server can fetch external API anytime, then I need to find a consistent way to support this scenario.

Please see the attached diagram for visualization.

Thanks

enter image description here

Upvotes: 0

Views: 2165

Answers (1)

Ján Halaša
Ján Halaša

Reputation: 8421

Since you need just a single token record for a user, the user table could be a good storage for it. You can consider creating a new one-to-one associated table for it, so you can apply any necessary constraints (not-null and such). You can also use any other safe storage.

You must store the refresh token. Whether to store access tokens and their expiration times (from the /token endpoint response), depends on how often you fetch the patient data. If your scheduled task period is longer than the access token lifetime, then you don't need to keep them in a persistent storage. Otherwise, you can store them along with their refresh token.

I don't think there is some general approach, since the solution depends on your requirements and architecture. You can consider storing the tokens in an encrypted form to improve security. I guess you do it with other patients sensitive data anyway.

Just for clarification, the flow you are using is called the Authorization code grant.

Upvotes: 1

Related Questions