OAuth2 vs traditional per request authentication

Question

User-131675163 posted

Hi,

I am about to create a new MVC ASP.net based Web API project that will allow vendors to access my API to request some data. Every request is different and at a different time interval. This API will carry some ePHI too, so it will have data at rest and in motion secured.

I am little confused on what authentication should I use for this project between OAuth2 vs traditional authentication against every request. I see traditional authentication of having auth details in every post request is going to be simple and helpful as I do not have any requirement of using session or token ID from one request to the next requests. I am in the impression of OAuth2 will always need first request to generate the TokenID and 2nd request for the actual data processing, which is just unnecessary for me. The token is not really required to me as all my API requests are single calls on demands only.

Can I still go ahead with traditional authentication and be enough <g class="gr_ gr_22 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" id="22" data-gr-id="22">secure</g> and no need to worry about OAuth2? What will I gain additionally if I go with OAuth2? Will the OAuth2 only work with token only OR it can also have per request authentication?

Thanks in advance.

Traditional authentication

URL - https://K58testQA.qa.com/io/UserList
{"auth":{"appId":"abc","appPassword":"xsad23%^dyasdf","accountId":"testaccount"},"someAttribute":"SomeValue"}    

Answer 1

User1724605321 posted

Hi gaims1,

That depends on your requirement . For example , in token based authentication , you can authorize only the requests you wish to authorize , after the server issue the access token , you could use that access token to access the protected web api resource before the access token expires . Before access token expires , you doesn't need to acquire access token from server , just setting token in  specific http headers . Another thing is do you need the feature that enable SSO between each client application ? If yes , you should look the OpenID Connect .  If you are in an internal network, the traditional authentication is acceptable with SSL enabled .

Best Regards,

Nan Yu

Answer 2

User-131675163 posted

Hi Nan Yu,

Thanks for the response. Yes, the token is helpful to ensure the subsequent web API calls are protected. In my case, I am going to have a single request at a time from the vendors say everyday evening 11 PM there will be a single call to get some data. I was thinking to use traditional authentication of passing the auth details within the post request itself. It helps to keep only single call avoiding the double call for Token and then actual API Call and still achieve the same security. Is it still okay to go ahead with traditional auth?

Answer 3

User753101303 posted

Hi,

Seems the first question would be to see where is the authentication information. The real benefit is that it allows to separate who is authenticating the client and who owns the accessed resource.

In your case it seems you'll both authenticate the client and own the resource so it seems a "traditional authentication" could be enough.