We Keep Coding

java jersey build a login/password consuming endpoint

I want to build a rest authentication endpoint with Jersey. I have already done it for a regular form on page:
#POST #Produces(MediaType.APPLICATION_JSON) #Path("/login")
#Consumes(MediaType.APPLICATION_FORM_URLENCODED) public Response login(
#FormParam("basicbtoatoken") String basicbtoatoken) {
.....
}
But, now I need to build an api that consumer login+pass and issues a token for further communications. How to do that properly in jersey? Can I just pass login+pass in open mode like other fields and process them accordingly? Or is there any trick for that?

Dead simple: basic auth ContainerRequestFilter. I'm sure you can find a reference implementation with some googling. If not, basic auth base 64 encodes credentials into authorization request header. Your back end credential store will be hit on every request to authenticate.
Nowadays this is typically solved via oauth2 protocol; a client gets a valid bearer token by various means. This is a short lived token added to the authorization header; encrypted with a trusted key (usually JWT) decoding it and checking basic sanity such as expiration is considered enough to authenticate. Credential store is only hit as often as you need to refresh this token (I've seen anything from 15 minutes into several hours)

How to use token based authorization on REST?

So after reading lots about BasicAuth, OAuth, JWT... etc. i came up with this question.
I have a client where some ppl can log in (Authentication is done). When ppl want to do an api call they use the clients GUI and the client is sending some requests to the a webservice endpoint.
host/resources/{id}
//id=path, res=post
public Response updateResourceById(String id, Resource res) {
....
So a typical update call could be
POST host/resources/1234 -d={ some json for a resource }
Now i don't want every user to have all rights for every reosurce, so i would
need to add some info about the user who is doing a request.
For this i was thinking to use some JSON Token with some payload (or any user info at all). But i was wondering how to send this token correctly in a RESTful API.
My first idea would be to change the code to something like this:
//id=path, token=post
public Response updateResourceById(String id, Token token) {
...
The endpoint would not change only the POST data.
Would this be correct or are there other approaches?
Edit: Also possible would be sending the Token via HTTP Header.

Sending credentials in HTTP
In HTTP, the credentials should be sent in the standard HTTP Authorization header.
Have a look at the RFC 7235, the current reference for authentication in HTTP 1.1:
4.2. Authorization
The Authorization header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Authorization = credentials
[...]
Please note that the name of this HTTP header is unfortunate because it carries authentication data instead of authorization. Anyways, this is the standard header for sending credentials.
In a token based authentication, the tokens are credentials. In this approach, hard credentials such as username and password are exchanged for a token that is sent in each request to identify a user.
It never hurts to say that you should use HTTPS when sending sensitive data, such as credentials, over the wire. HTTPS will protect your application against the man-in-the-middle attack.
Reading the authentication token in JAX-RS
You can read the Authorization header in a JAX-RS application as following and then check if the token is valid:
#GET
public Response myMethod(#HeaderParam("Authorization") String token) {
...
}
However, a better approach would be using a ContainerRequestFilter, keeping your endpoints leans and focused on the business logic. For more information on token based authentication and on how to use a ContainerRequestFilter, have a look at this question.

Does it needs to pass username:password combination in any request with basic auth?

I confused with basic http authorization. It is needed to send every request to server with Authorization header or just first one and after that browser rember auth tokens like session id?

You have to send the Authorization header on each request. But for example Chrome remembers the auth tokens and sends it automatically on each request.

Using basic authentication, every request needs to have an Authorization HTTP header in the format:
Authorization: Basic <base64(username:password)>
where the username and password are concatenated using a colon (':') and the resulting string is base64 encoded.
If the Authorization header is not part of the request, or the credentials inside are not valid, the server should respond with an HTTP 401 Unauthorized response and include a HTTP header like:
WWW-Authenticate: Basic realm="myRealm"
Basic authentication is an implicit authentication scheme, so after the user enters valid credential, the browser will send them along with each page request.
For AJAX requests you'll need to attach this header from code. However, you really should not use basic authentication to protect an API, for a number of reasons:
You'd force the client to hold those credentials in code, where they can easily be stolen.
You must use HTTPS with basic authentication as base64 encoding gives no protection of the credentials at all.
Username/password combinations are usually valid much longer than an access token, thereby increasing the risk if they get stolen.
Password validation should be a slow process to mitigate brute force attacks, where token validation is just verifying a digital signature.
Having to send the username/password over the wire every time increases the attack surface for someone trying to break the encryption.
Better alternatives to protect web APIs are token based authentication schemes like OAuth2 or HMAC based authentication schemes like Hawk or AWS

Ya that's correct , so for first time when user logs in , his credentials are verified against some data , if correct , a auth token is generated.
Auth token is pretty much a self contained entity (which stores some data signed with a key)
this token gets stores at client side(usually along with a refresh token)
for all subsequent requests , this token is kept in Authorization header(Bearer+token)
When server receives this token , it decrypts it with the key , which it used earlier to sign that token. And uses that stored data
If that auth token is expired , refresh token comes into play.
some links to begin with
On a high level, how does OAuth 2 work?
and jwt.io to get the feel of tokens

How to Obtain request_token from dropbox

The Request Token and Token Secret MUST be exchanged for an Access Token and Token Secret.
To request an Access Token, the Consumer makes an HTTP request to the Service Provider’s Access Token URL. The Service Provider documentation specifies the HTTP method for this request, and HTTP POST is RECOMMENDED. The request MUST be signed per Signing Requests, and contains the following parameters:
oauth_consumer_key:
The Consumer Key.
oauth_token:
The Request Token obtained previously.
oauth_signature_method:
The signature method the Consumer used to sign the request.
oauth_signature:
The signature as defined in Signing Requests.
oauth_timestamp:
As defined in Nonce and Timestamp.
oauth_nonce:
As defined in Nonce and Timestamp.
how to get these parameters in java

AppKeyPair appKeys = new AppKeyPair("INSERT_APP_KEY_HERE", "INSERT_SECRET_HERE"); //Both from Dropbox developer website
WebAuthSession session = new WebAuthSession(appKeys, Session.AccessType.DROPBOX);
DropboxAPI<WebAuthSession> mDBApi = new DropboxAPI<WebAuthSession>(session);
System.out.println(mDBApi.getSession().getAuthInfo().url);
The URL contains all the information need I believe.
Dropbox API downloaded form here: https://www.dropbox.com/developers/reference/sdk
Go here to get App key information:
https://www.dropbox.com/developers/apps (Must sign in to dropbox and create new app)
You don't need all the extra stuff other than oauth_token if you connect over https.

If you're using the HTTP API directly, you can get a request token via the /oauth/request_token call.
Instead of using the HTTP API directly, you might find it easier to use the official Java SDK for Dropbox. Documentation on the OAuth flow: WebAuthSession.java.

passing parameter in http header with REST service

Right now i'm using java to build rest service, and trying to use spring security to securing my service.
I have a few parameter that server needs to process the service (ex: application ID, username, password, consumer ID) . For username and password, I put in on http header "authorization", encoded with base64. Is there a way to put another parameters above (ex. AppID, consID) into http header?
Some sample of code would help, thanks.

You can put whatever you want in a whatever header you like. You can create custom headers. So you can have a App-Id header where you pass the appId. Alternatively you can pass those as parameters in the URL. That way you'll get rid of the option that some (stupid) proxy trims your headers.
Btw, I would suggest not to send the password, unless you are using https. Generally, I can recommend two similar scenarios:
use OAuth - let the user grant access to the API client via the OAuth dance. The client ends up with a token which it uses on each request.
use a custom, simplified token scheme - login once (with username and password, over https), and send a short-lived token in response. Each subsequent request can be made over an unsecured connection by providing the token, and (optionally) some HMAC of the request parameters, using a consumer secret as a key, so that you can verify the client is legit.