CODEWITHSUNDEEP
c#restasp.net-coreoauth-2.0dotnet-httpclient
ashilon
ashilon

Reputation: 1941

Are OAuth access tokens user specific?

We need to add new functionality to our web app, which is written in asp.net core 3.1 and angular, which creates new scheduled meetings in Zoom (the video conferencing services provider). Currently this is the only requirement, so on the face of it it sounds simple. And indeed their api is well documented and easy to use. Now, since we're using asp.net core on the server, we can use its caching capabilities, like session, in memory chaching (IMemoryCache) etc. The piece of knowledge that i am missing to complete the picture is about OAuth access tokens. I'm not sure whether an access token that is issued by Zoom is specific for the user that has just been authenticated/authorized and wants to create a new meeting or for our web app (let's call our web app the client, by OAuth's terms). So the meaning of this is that we need to choose the right storage mechanism for access tokens. If it's at the user level, ie specific to the user of our app currently using it, we need to store the token in asp.net core's Session storage, but on the other hand if the token is, let's say one level above we need to store the token globally, maybe in the memory caching of asp.net core, the IMemoryCahce stuff. This is the main issue i need to understand. Regarding keeping the access token on the server, that is the best practice as far as i have understood from reading some material on the subject.

Thank you very much,
ashilon

Upvotes: 1

Views: 439

Answers (1)

Randy
Randy

Reputation: 1255

To answer your question, assuming the authorization code flow is being used, yes the access token is specific to a user. This is because the token is the result of an authentication performed by an individual user within the 3rd party OAuth provider.

Although client access tokens are a concept within the OAuth specification, 3rd party user-facing applications typically don't give wide-ranging permissions and stick to a user-by-user basis (not even supporting the client_credentials grant).

Upvotes: 1

Related Questions