Token isn’t more or less secure… just different. here’s info on it how to use it. It needs to be enabled from Admin console. http://jcg.pictures/gdggGkKdWHF.png
Like Jose said, it’s not more or less secure, just different. I would not do any web service without https these days - even my Intranet. It’s not that difficult to do anymore and it can be done for free using LetsEncyrpt.org. In the upcoming world of Progressive Web Apps, it is required so just get used to it. It is the new lowest common denominator in web security.
One slight confusion here… The difference between ssl encryption and token authentication. I feel an old incomplete whitepaper is laying around to help. Let me dust it off and update it…
So you are saying that once the TLS encrypted connection is made between IIS and the client browswer, sending basicAuth encoded string (username/password) is as secure as sending a token. Since the wire is already encrypting things, that is all the security one needs? Or am I reading this wrong.
Also a quick pros/cons or use cases where basicAuth works better or worse than token auth would be useful (aka guidelines).
Once Https encryption is established (SSL or preferrably TLS), then yes the communications are encrypted.
Basic Auth is logically just a clear yest username and password. How are you caching that in the client? Are you saving it in clear text across a few pages in whatever app integration you have? This is where Basic Auth falls down - the passing of clear text credentials around on a client.
Token Auth instead has an isolated area where the credentials are entered, sent to the Token Provider, then the token is passed around. It has a defined lifetime as well as set by an admin so you have a lessened exposure for exploitation.