Last post May 27, 2014 02:16 AM by Sam - MSFT
May 25, 2014 06:37 AM|RobTFC|LINK
May 27, 2014 02:16 AM|Sam - MSFT|LINK
Which of these approaches would be deemed the better?
The Second approach is will be better if you take my suggestion. Now, SSA is the future. Users on the web are getting more and more used to it. So, you may take full advantage of the OAuth. It is easy to use OAuth with ASP.NET.
If I do go down the Web API and OAuth route, how flexible is the OAuth middleware? For example can I configure it to read from the database of my service as opposed to the database structure it generates as part of the template?
It's quite flexible. You may add custom fields and information to it easily.
the client app have to implement renewal itself based on token expiry? Also how are authentication "scopes"(?) defined in the OAuth config, to give a list of what actions a bearer token holder may have rights to. I'm not interested (yet at least) with interfacing
to another online provider. Is the OAuth middleware deemed a replacement for the classic non-Owin auth mechanisms such as forms auth, or just another option?
It is quite easy to Access the Token and use it. You may use cookie or QS to pass query.
To know how the Access Token works you may refer to the following article:
You may also use both Membership and OAuth both in a ASP.NET website. Both can coexist.
The tutorials and videos make this appear easy and obvious but there seems to be some gap between a 5 minute demo and an actual system. Perhaps OAuth isn't meant to fit my scenario?
Every approach will have some pros and cons. But OAuth is the future. If you currently see the web. Most are adapting it.