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
Related
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
We have our own existing we portal in ASP.NET MVC, now our one of the customer do not want to use our portal as separate tool, instead they want to consume our feature via WEB API and consume it on their side.
Now I want to implement authentication and authorization in web API, I did google to find my question's answer, but didn't get it.
I am confused in below points.
Is it best choice to OWIN the default implementation which Microsoft provide? or some custom implementation?
What are the advantage and disadvantage to use OWIN in terms of security?
When to Use JWT (Json Web token) and OWIN?
Or any other implementation which help to create more secured web API?
Looking for all expert's valuable to input to help me to decide.
I implemented something similar. This is how we work: we have our application (MVC app) which permits us to login. Logging in uses a separate mvc project (our STS) which handles all user authentication. When our login and password is posted correctly, we generate a JWT which is returned to the MVC app. Back on the application side, we decode our token and build up the claims in it in an asp.net application cookie.
We also have a separate project containing our WebApi REST methods. Those can only be called by using the JWT generated by our STS. We elaborated this more with a custom attribute so we can set permissions on specific permission or role claims that are in the token.
For creating all of this, i was helped very much using these series of articles: http://bitoftech.net/2014/10/27/json-web-token-asp-net-web-api-2-jwt-owin-authorization-server/
In terms of architecture this is in my opinion 'how it should be' but i am not an expert in this.
So summary:
Web Application - application cookie to authenticate/authorize
Calling WebApi Rest methods - using the JWT to authenticate/authorize
Separate STS which takes in POSTS to authenticate and generate JWTs
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.
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