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.
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.
Related
I am learning Spring and have written a simple RESTful web service that is not intended for browsers but for native mobile apps only. When trying to implement basic authentication for users. I've hit a wall, because the sources (even official tutorials) assume (and recommend) using OAuth2 through a browser with SSO and\or social logins.
All I want is to create an API RESTful endpoint that will take an email address and a password and return a token (possibly JWT). I do not need extended support for roles (but am not against it) and dynamic token revokation if that matters.
Is there any easy library/solution/tutorial that focuses on something similar?
Edit:
Thanks for the answers — all of them shed more light on the auth process and are quite useful and on point!
Please check here, I have a working example for the spring security on my github. You may need to change the spring.active.profiles=jwt, to enable the jwt configurations on this project.
There are many tutorials available on internet for implementing JWT token based authentication using Spring Boot. Please find below some of them
https://dzone.com/articles/spring-boot-security-json-web-tokenjwt-hello-world
https://www.javainuse.com/spring/boot-jwt
Please go through them and try to implement. If you need a working code for reference, you can search GitHub for code. This is one of them https://github.com/murraco/spring-boot-jwt
Confusion about API auth types in Laravel?
I'm currently learning how to create an API in Laravel and I found myself into this confusing concepts. After a few days of research and practice, I could finally understand enough this concepts to make a mini-guide. I had to look into a lot of separate webpages so I will make my best attempt to explain the relationship between them.
What are these concepts?
Passport is an official Laravel package that implements Oauth2 and JWT.
Auth0 is an authentication and authorization service. It is kinda "all in one" solution for API auth. It implements JWT by default and can implement Oauth2 as well as many other protocols.
OAuth2 is an authorization framework or protocol that enables applications(the ones you're going to build) to
give limited access to user accounts such as Facebook, GitHub, etc... Imagine that your app grew big enough to offer a "Sign in with APP NAME HERE" or provide limited access to your users account to other third-party applications. With Oauth2 you can achieve this among many other things.
JWT is a token format. In other words, it is how data will be arranged to create a token. Another token format would be SWT.
In other words:
Passport implements -> Oauth2 and JWT.
Auth0 can implement -> Oauth2 or many other protocols like LDAP, OPEN ID, etc...
Oauth2 can implement -> JWT or other token formats like SWT...
What should you use?
Not only it would be crazy for a beginner to create its own Oauth2 implementation compatible with Laravel, but also chances are that if you're reading this is because you don't know exactly how to all the Oauth2 complexity. Oauth2 out. All we have remeaning is three package options. Passport, tymondesigns/jwt-auth and Auth0.
Before continuing, let me note that when I refer to 'JWT' or 'plain JWT' I really mean to the tymondesigns/jwt-auth package. The real match comes between Auth0, Passport and plain JWT...
Auth0 is a Swiss army knife compared to Passport and JWT. This knife is an all in one solution. It can do a lot of stuff on its own plus some extras that you might never need without depending on Laravel or other frameworks. To not extend this too long, let me just say that it can do whatever you could possibly imagine as an API beginner. Also, you would have a really good dashboard straight out of the box which will allow you to manage all aspects of your API. From third-party authentication to add more apps (mobile, web, desktop) that can consume that API.
Passport could be compared with a more delicate knife. Its creators knew what it will cut and designed it specifically for those tasks. In other words, it was built especially for Laravel to work smoothly and flawlessly without having many bells and whistles bothering around. Though, don't forget that in the long run you can implement your own code on top of it. Like a nice and custom dashboard to manage your API clients.
Finally, back to the knife analogy, I like to compare JWT with a sharpened blade without any fancy extras. It's lightweight, functional, secure and does its job. You get the benefit that you will not have to worry about all extras that the other packages add. Furthermore, you can upgrade this knife however you want due to its flexibility or even switch to another package if you need a heavier upgrade.
Conclusion
It depends on you, if you want to cut everything that might be thrown at you and stay more in the API world than in Laravel (Auth0), narrow down to the focus of Laravel and Oauth2 for third party authentications (Passport) or have a basic secure data transfer out of the box via API (JWT). And yes... You can also link your app to your mobile app with the three of them.
Personally I USED to prefer Passport because:
I like to work with the official Laravel packages.
Besides the many extra routes and tables added to my project, its performance will not be affected.
If I started with the most basic API auth and wanted to scale, it would be much easier.
The coziness of working with a Laravel Package.
Still talking about the last point, some may say that Auth0 community is small. It basically is, but also it has awesome client support personnel.
Edit: (Now I prefer Tymon JWT)
Tutorials on Passport and Oauth2
Laravel and Oauth2 Docs explanation of tokens might be a little difficult. Here is a Good Explanation of Passport's(therefore Oauth2) Different Types of Tokens and Their Use Cases. Since I couldn't figure out the "routes" part of the tutorial I wouldn't recommend the tutorial part.
This is a Good Passport Video Tutorial which also uses the PostMan Chrome app for API calls. For those of you who are new to this API stuff, apps like PostMan will make your work a lot easier than using a "curl" Linux/Mac command. You could watch the complete series or just the Passport part. At the moment I'm stuck on video 4. Here's my Stack Overflow question.
Resources
Many of the resources are all spread above in the article but I also have some here.
Stack Overflow JWT vs Oauth
Auth0 explanation of Oauth2
An Introduction to OAuth2
OAuth2 Simplified
I have created a Java Spring app with the idea to work as a server app for a web app (build with angularjs or reactjs, not defined yet) and a mobile app without any security concern. Now, I need to add security/authentification functionality. I was looking for the best approach for this, and I found that I could use JWT (JSON web token) for it.
My questions:
Is JWT ok for this approach? I mean, for my own authentification
system using a database, not just facebook/google login.
Is it better to start again having an app with the authentification
working and then add the business functionality (not too much) or it
is better to add the authentification to my existing app?
Do you have any example, step by step tutorial? I cannot find one that do
what I'm expecting.
JWTs are a very good authorizantion method for mobile apps. The two main advantages of JWTs in my opinion are: The user has to login just once and fewer database accesses are necessary (of course it depends on your implementation).
I always start with authorization first. I think this way you get cleaner code, but you have to decide if it is worth in your case to start new.
If you understand the basic concept of the JWT (JWT introduction) you just need a Java library (JWT libraries) and you will understand the description in the repository good enough to use it.
We're developing an API and a single page application (that is one of more possible future consumers of it).
We already started on the web API, and basically implemented a system very similar to the one John Papa made in his course on pluralsight, named "Building Single Page Apps (SPA) with HTML5, ASP.NET Web API, Knockout and jQuery".
We now need to implement authentication and user managing in this application and need to find the easy way out to implement this in as little time as possible as we are in a hurry.
We realized the SPA template included in the ASP.NET update had very similar features to our needs, but we wonder what the best approach to implement a similar feature in our existing code.
We are novice developers, as you might figure.
Is it possible nstall some packages using the package manager, and voila, a simple membership and OAuth auth option be readily available?
Our use case is that we need to protect some resources on our API based on roles, and that one should be able to log in using a username and password, but also log in using ones facebook, google, or twitter account.
Found an interesting talk regarding the subject here: https://vimeo.com/43603474 named Dominick Baier - Securing ASP.NET Web APIs.
Synopsis: Microsoft’s new framework for writing RESTful web services and web APIs is appropriately enough called ASP.NET Web API. As the name applies, this technology is part of ASP.NET and also inherits its well-known security architecture. But in addition it also supports a number of new extensibility points and a flexible hosting infrastructure outside of IIS. There are a number of ways how to do authentication and authorization in Web API - from Windows to usernames and passwords up to token based authentication and everything in between. This talk explores the various options, and puts special focus on technologies like claims, SAML, OAuth2, Simple Web Tokens and delegation.
We eventually went with the SPA template, doing authentication on the API (separate MVC part).
Then the API would generate a unique token and redirect the user to the front-end with the token in url parameters.
The front-end then needs to send this token on every subsequent request.
Have a look here - Identity Server done by the security experts. This is all you need in one package.
In terms of OAuth, you would need to use Client-Side Web Application flow which the access token is issue immediately to the client and can be used.
I've searched the posts and have not found exactly what I'm looking for pertaining to my question. For example Security ... through AD asks more the question is it wise? My question is this:
We are implementing WCF applications and we are now putting WCF ... I mean ASP.NET Web Api ;)
into our server stack. I want to secure the services by requiring that the user log on to ADS, but if they already have logged on (via network login or other means) then I don't request a login. Rolebased authorization then occurs within the services.
I cannot find good discussions or examples of how I handle ADS authorization especilly through all of the future endpoints (tablet and phone).
My one thought was that the user does a login to ADS and the token then becomes what gets handled for security and rights. So now I'm a little bit concerned about how much coding has to be done to accomplish this. We are looking at FederatedServices to handle this in WCF but there is no such control in this weak API.
So I'm interested in any input or direct me to a great article on this. So far all I see is self-rolled security which our old server has and I do NOT want that crap again.
Oh yes, did I mention our target is single signon throughout our web services??? :)
Best place to start is Dominick's Thinktecture Identity for Web API. It is the de-facto security framework for Web API and supports token based identity.