We Keep Coding

How does server return JWT token to the client?

This is my first encounter with a JWT token and I'd like to know how is this token returned to the client after it's first created.
Should it come in the Authorization : Bearer header ?
Usually, it's the client that passes the token in Authorization : Bearer header on each request.
I'd like to know how does the server pass this token to the client after user has authenticated and the token gets created. Also in the same header? In a different header?
In my situation, the server will be generating the token not as a response but as part of the request.
For example:-
A user will login to a portal, then click on a link to an authorized application. The JWT containing user claims will be passed to the authorized application as part of the request.
What is the best approach here? GET or POST? Header (which)? Query string? POST body?
Thank you!

there is no standard for how to return JWT token to the client, however, check this URL, it answers your question
https://github.com/dwyl/hapi-auth-jwt2/issues/82#issuecomment-129873082
putting the JWT token in the Authorization header gives us flexibility to send an actual response in a web application. For a REST-only App/API you are free to send the JWT as the response body or a cookie. What matters is how the client stores the JWT and sends it back to the Server, which is done in the Authorization header (or Cookie or URL Token if you prefer) 👍
As for this existing in the "wild", I have not seen an example of the server sending an Authorisation header to the client, but there is nothing in the spec to suggest this is an anti-pattern.
see: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html
If you want to stick to the guidelines you would do follow this example: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#ExAccTokResp

One may be interested to know that the OAuth 2.0 standard specifies the response body for that purpose:
5.1. Successful Response
The authorization server issues an access token and optional refresh
token, and constructs the response by adding the following parameters
to the entity-body of the HTTP response with a 200 (OK) status code:
access_token
REQUIRED. The access token issued by the authorization server.
[...]

Refresh access_token via refresh_token in Keycloak

I need to make the user keep login in the system if the user's access_token get expired and user want to keep login. How can I get newly updated access_token with the use of refresh_token on Keycloak?
I am using vertx-auth for the auth implementation with Keycloak on vert.x. Is it possible to refresh access_token with vertx-auth or Keycloak's REST API itself? Or what will be another implementation of this?

keycloak has REST API for creating an access_token using refresh_token. It is a POST endpoint with application/x-www-form-urlencoded
Here is how it looks:
Method: POST
URL: https://keycloak.example.com/auth/realms/myrealm/protocol/openid-connect/token
Body type: x-www-form-urlencoded
Form fields:
client_id : <my-client-name>
grant_type : refresh_token
refresh_token: <my-refresh-token>
This will give you new access token using refresh token.
NOTE: if your refresh token is expired it will throw 400 exception in that you can make user login again.
Check out a sample in Postman, you can develop and corresponding API using this.

#maslick is correct you have to supply the client secret too, no need for authorization header in this case:
http://localhost:8080/auth/realms/{realm}/protocol/openid-connect/token
In case of expired refresh token it returns:
If you don't add the secret you get 401 unauthorized even though the refresh token is correct

I tried with 4.8.2.Final, it gives following unauthorized_client even with previous access token as 'Bearer'.
Then I tried with Basic YXBwLXByb3h5OnNlY3JldA== in Authorization header.
Then it worked, But still I'm not sure that I am doing right thing.

Extending Yogendra Mishra's answer. Note that
client_id and client_secret can also be sent in Authorization header.
Authorization: Basic ${Base64(<client_id>:<client_secret>)}
This works for both initial token call (without refresh token) and refresh token call to /openid-connect/token endpoint
Reference:
https://developer.okta.com/docs/reference/api/oidc/#client-secret

Implementing a token style security when doing GET requests

I'm implementing a temporary and very simple token-style authentication mechanism for an application.
The idea is very simple. Whenever a user logs in to the application, a token is returned to the client, which stores it in the sessionStorage data structure of the browser.
Now, whenever I do a request through AJAX I can send the token with the request and the server can verify if this token is associated with an authentication or username. If it is, it parses the request normally, if not, a error page or the initial page is returned or displayed.
I'm not sure if this is the way that token-style authentication and authorization is implemented in real or serious applications, but I've now no idea how to send the token when doing GET requests by just clicking on the link of a view.
My only idea would be to intercept the get requests so that I can fill them with the token, but this all seems to be quite odd, and I've already a lot of links and views.

Search for Json Web Tokens and for implementations on java. This is exactly what you need.
If you want to send to the user some sensitive data inside the jwt, use Json Web Encryption.
You can send that token on each request header or as a request parameter

You can set a cookie, ensure to set it httponly (ans secure if you are on an https site) and read the cookie on every request that reach the server.

You can use JWT token (see https://jwt.io/introduction/). JWT is basically a JSON data structure. Usually, the token is passed along in the authorization http header.

Using Java and OAuth 2.0 how to maintain the session

How to maintain the session by using OAuth 2.0 ?
Like I logged into the Android application , now I want to make user logged in till the user dont logged out manually , so for each span of time and the request the token will change.
How should I handle the same in my Android Application ?
Can Anybody suggest ?
Thanks
Dhiraj

Store the expires_in field and refresh_token delivered along with the access_token, and the unix timestamp of when the token was delivered in somewhere like SharedPreferences.
The next time you need to use something that requires authentication, double check the current unix timestamp with the unix timestamp delivered when you obtained the original access token + the expires_in*1000.
If the current timestamp is greater than the sum of those two, your access_token is expired, and you need to send a request to the authentication service for a new token, using the renewal_token, client_id, and client_secret to the OAuth endpoint.

You can also use this url: https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=your_access_token and get json response like below for valid token:
{
"audience":"8819981768.apps.googleusercontent.com",
"user_id":"123456789",
"scope":"profile email",
"expires_in":436
}
and for invalid token:
{"error":"invalid_token"}
For more information, check this link: Using OAuth 2.0 for Client-side Applications, there is a heading Validating the Token that explains this procedure.

OAuth has no concept of a session. Each REST request needs a valid access token in the Authorization header. Any "session" you want to implement is your responsibility. Any access token you acquire will TYPICALLY (not necessarily) last for 1 hour, but that is NOT the same as a session.

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.