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.
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
I start building a new app and wonder what will be the best way to implement auth - security wise.
What are the cons, pros, and differences between the Laravel make:auth and using jwt-auth.
Is Laravel's default auth will be enough?
This description is pragmatic approach so you can do something else if you want.
I think while developing an API you should use JWT based authentication mechanism.
The Json Web Token(JWT) tokens includes user information in itself. So it giving so much important benefit to manage session. First and most important of the benefits is you can be manage sessions without storing them at server. I would like to explaint it just to avoid misunderstanding, you can have store it at server but it's not necessary except a few scenario. These scenarios depend on how you could designed your authentication.
I able to do a lot of more explains about of it but in summary if you are developing an API I propose you would use JWT-Token.
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 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.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D