Moving from Web API 2 Claim-Based-Authentication to ThinkTecture

Question

I am finding that Microsoft's implementation of Claim-Based Authentication is not really up to the expectation of the true Claim-Based setup, and I seems like ThinkTecture is doing a good job of replacing Web API implementation.

I am wondering if anyone has a guide or blog post for people to move from the default SPA Template for VS2013 for AccountController to the ThinkTecture approach.

I also like that default Microsoft Web API AccountController that will create the tables for AspNetUsers and Roles, but I am not sure if ThinkTecture does the same thing or not.

I guess I am a little confused between all of the repositories that ThinkTecture have. Does any one have a solid guidance in terms of what to use, IdentityServer, IdentityModel.45, or AuthorizationServer?

I am just looking to drop the whole Microsoft approach and open to use a proper true Claim-Based approach, but I kinda need help in terms of EF6 migrations for the Identity tables, and what projects to use, or how to drop the the whole AccountController approach in SPA-Template for VS2013. I have looked at Dominick's blog and it seems to be really good, but I haven't found a post that kinda helps moving from Web API approach to ThinkTecture way of thinking.

Wintery

Answer 1

Thinktecture Identity Server is for issuing authentication tokens (for things like websites) and is helpful for SSO (again, in browser scenarios).

Thinktecture Authorization Server is for issuing authorization tokens (for things like Web APIs). Authorization Server needs the user to authenticate, and so it can rely upon Identity Server for that.

Thinktecture IdentityModel is a helper library you'd use in either a web app or Web API app to help with various security concerns that aren't provided by the .NET framework.

Chemotropism

Thanks @Brock for your comment. I have looked at your MembershipReboot project, and I am wondering how does that come into play. From what I understand, MembershipReboot does the Authorization and Authentication together (in a way it could replace IdentityServer or work along side with it through MembershipRebootUserRepository, and replace AuthorizationServer), but it's not using the Bearer Token approach, instead it uses the Cookie based approach through its AuthenticationService. If so, do you have any input in terms of Bearer Token vs Cookie based approach? I may be wrong about this. – Wintery

MembershipReboot is about identity management and authentication. One optional piece is the cookie piece, but it's not mandatory, so if you wanted to use it from your own OAuth2 authorization server, you could use it for validating the credentials. Your authorization server would then issue the token (which is not the role of MembershipReboot). – Chemotropism