Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am developing a REST API with Java using Jersey and what is the best way of securing it? I looked at various things from password based authentication, Servlet Context , and I heard about tokenization and so on. But what is the industry standard way to secure it and make sure nobody can get data from a GET request by just typing the URL in browser, simply make a POST calll from PostMan and so on? Any learning materials on implementing this best way?
In simple English, what i am asking is, how can I secure my REST API by making sure the API is accesible only to our app?. The method of doing it can be anything from password to token. I am learning it now trying to implement it, but before I need to know what to learn, because I am looking for the best practice and industry standard way of doing so.
Here is pretty good place to start to secure your API:
Use HTTPS
Use username/password for authentication
When user successfully logs in, you generate a token for them
Assign the token to that user (easy way is to save it in a DB)
Require the user to send that token with every request
Validate the token before responding to any request
That being said there are some concerns. You should research how to achieve these:
Store credentials in your DB in an encrypted form in case your DB is compromised.
If you store your tokens in a DB, validation requires a DB lookup, will that be an issue, are you expecting heavy load?
If you use a stateless authentication, for example a JWT then how do you revoke access if you need to. (Hint: look into access+refresh token scheme + a blacklist)
How do you transport your token(s), header, cookie?
Protect your API from cross site scripting(a.k.a. XSS) and cross site request forgery(a.k.a. CSRF or XSRF).
NOTE: these are just some quick thoughts off the top of my head, you can find a lot of information about these online.
Related
This question already has answers here:
How can I suppress the browser's authentication dialog?
(12 answers)
Closed 5 years ago.
First of all, I'm not 100% sure what I'm asking is a right thing to do or not. So please free feel to correct me if I'm wrong.
Using Spring Security, I've developed a REST API backend which users can log in using some custom entry. If my users authenticate themselves using my custom API, there will be a session created for them and the rest of API entries will be accessible to them, considering their role and ACL.
At the same time, these APIs are designed so they can provide services to other software. So I thought it makes sense to enable some HTTP Basic Authentication as well. Later on, I might be working on digest as well. And if some request is authenticated using one of these methods, there will be no session created for them. And they'll need re-authenticate for every single request. It's a stateless API.
So far everything is great. The users and other systems can make use of the same sets of APIs. But the problem is when a user's session is expired. Or when some user starts using the backend services before he logs in. In such cases, the right strategy is to redirect the user to a login page and ask them to authenticate themselves. But since I've enabled the HTTP Basic Authentication, calling a REST API which needs authentication (while the user is not authenticated) leads to a browser popup asking for the username and password.
Of course, the user can enter the credentials and keep using the system. But I don't like this way of authentication for my users. First of all, the authentication credentials will stick and I consider it a security risk. They are easily be saved into the browser without informing the user they are. And it's hard to get rid of the saved credentials. The user can leave the computer without even knowing that his username and password are saved.
So my question is, is it possible to have Basic Authentication enabled but at the same time, prevent the browser from knowing it? Or even better, acting on it?
I suspect that if I prevent the WWW-Authenticate response header on the way back, I might be able to do so. But then, I'm not sure of the ramifications of such a decision. Also, I don't know how to remove that header from the response for all of the APIs.
I think I rushed into asking a question without researching it thoroughly first! This post answers it perfectly!
How can I supress the browser's authentication dialog?
The solution: add a X-Requested-With: XMLHttpRequest header to your request.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I have multiple java web applications all having their login functionalities. I want to apply SSO(Single Sign On) on them irrespective by any method.
I have spent last 2 days on finding a solution to it, but I have no result.
Please anyone can help me on that.
My requirement is:
1.If user logs onto a single application he would be automatically logged onto other applications.
Sorry for my English and Thanks in advance.
If applications are in a Windows intranet and use windows logins, Waffle will do the job. Otherwise develop your own simple ticket granting service to provide SSO among your applications.
Update:
All of your apps have to have filters. Filter sends the session/cookie data(if available) in order to verify, to your SSO service whether the incoming request with the principle is already granted or not. If the session or cookie is not associateed with a ticket, then you redirect to the login page. If the request is about to login, then filter sends them in to SSO service, verify user and password with your database, and add an entry to SSO MAP, saying "this user just logged in". So it will send a ticket for that login. Ticket means just a random generated id. If the SSO service could not able to validate the user, then no entry will be there in the SSO MAP and will send failure error to your filter.
So your user validation goes in to a separate service which I just named as SSO service.
You will have to remove idle entries from SSO MAP.
Read about how SSO works, you will understand.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
There is an email portal : email.me.com. To login into the portal,we need a set of credentials namely username and password. If the credentials are correct, we are able to login with a success message else a failure message is thrown.
Is there a facility available in Java/or is there a way, I can check if the credentials are correct. I want to check by sending the username and password over the code? Is there any way I can do it?
code ------> login server (email.me.com) ---->Auth/Failed
|
|
\ /
message<-------------------------
Java doesn't try to implement telepathic insight into web servers mostly for security reasons but mainly because no one could demonstrate such a technology is feasible.
What you can do is use a HTTP client framework like Apache's HttpComponent to talk to the server as if you were a web browser, fill in the form and submit it.
Or you can contact the site's owners and ask if there is an API which you can use (IMAP, REST).
Note: Your request sounds like "I want to crack accounts on this server". So don't be surprised if you run a few tests and suddenly find your IP address being blocked.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
last.fm API authentication
I need to connect to a URL, let user authenticate, and then proceed. How do I do that? I have the part for opening the URL, but do not know how to wait.
// 3. Request authorization from the user
String authURL = "http://www.last.fm/api/auth/?api_key=" + key + "&token=" + token;
java.awt.Desktop browser = java.awt.Desktop.getDesktop();
java.net.URI uri = new java.net.URI(authURL);
browser.browse(uri);
It's my first time working with web API's. I tried looking on Google and SO but didn't exactly find what I was looking for.
I'm sorry you chose this as your introduction to APIs. 5 seconds in the docs revealed that the question you have is a design flaw in their code, from the documentation:
If the user is not logged in to Last.fm, they will be redirected to the login page before being asked to grant your application permission to use their account. On this page they will see the name of your application, along with the application description and logo as supplied in Section 1. Once the user has granted your application permission to use their account, the browser-based process is over and the user is asked to close their browser and return to your application.
That's right. They don't ping you after the user completes the authentication. They just instruct the user to close the browser. That's pretty lame for obvious reasons: how do we know if the user completed it? We don't.
You're going to structure your application so the code continues after the user comes back, perhaps giving the user a button to press that says "I'm done". Later, you'll have to handle the possibility that the user never authenticated in your other code that calls the API.
Yes, it's broken. oAuth for example will at least call you back with a token after the user completes the browser based auth step. When using oAuth in a desktop app, you can just fire up a local webserver and receive your callback there (requires your LAN to be configured properly, obviously)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm starting to work on a SSO solution for 3 different webapps we've produced and still maintain for the same client.
Thing is, all 3 store their users and login information in the same place through a fourth separate application which provides just basic restful api services.
Which basically means that when one tries to log into, we actually call the rest service asking whether this username and password are correct.
In a way this fourth restful thingie already does at least half of the job we need.
What we need now is a way to let users log into webapp A, then follow a link (or simply type its url) to webapp B (or simply type its url) and get there already logged (or viceversa).
I've been reading a lot about CAS and openID or even oauth but can't really make up my mind about it.
Is this pattern centralized? Decentralized?
My ten-thousand foot view suggests I would somehow just need to add this "missing feature" to our restful api server.
But how?
ps: these 3 are completely separated. deployed on different machines (2 of them run on glassfish, the other one runs on tomcat). different domains too.
pps: they're all spring-driven webapps (hence they use spring-security)
ppps: as of today, there are other webapps using our restul api (non spring, non java).
this sso solution might have to be ready to handle those too.
Yeah it sounds like you need a "true" single sign on system rather than just a centralized credential repository. As you mentioned there are several options:
OpenId - more suited to an internet type application in which you
want to allow users to log into your systems with credentials that
are maintained by a third party. Stackoverflow is a classic example.
You can sign in with your google account etc.
Oauth provides Pseudo authentication and sso - whereas OpenId says
"this is user x" oauth says "this user has access to x's
information" ... so you can assume that the user is x.
CAS, Cloudseal, OpenAM etc all provide true single
sign on and are suitable for an intranet or extranet environment.
CAS and Cloudseal have especially good Spring support.
Trusted site (relying party (RP) in white list - app a,b,c in your case) make request (redirect) to main site (provider - "fourth separate application") with a return url.
Main site make sure request (returnURL) is from white list of domains
Log user (if not logged, displaying login form), mark user as logged in database and add temporary token to user database.
Main site return (redirect) to RP with token.
RP look into database using token, logs user and deletes token.
SSOff also easy: just check on every request into user database into bool record (userLogged). NO REDIRECTS. On logout simply change record (userLogged) to false and every site will know.