Last post Oct 31, 2018 05:58 PM by PatriceSc
Oct 08, 2018 04:53 AM|gaims1|LINK
Oct 09, 2018 03:03 AM|Nan Yu|LINK
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 .
Oct 26, 2018 09:12 AM|gaims1|LINK
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?
Oct 31, 2018 05:58 PM|PatriceSc|LINK
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.