We Keep Coding

what should I do when the client request to refresh the valid access token

I am write a refresh access token rest api, now I facing a problem that I did not know what is the right way to handle the refresh invalid access token request. For example, when the access token not expired, the client request for a new access token. should I give a new access token? or give the old token? or give the token by the expire time, if the expire than greater than 1 hour give the legacy access token, less than 1 hour, give the new access token.

Yes, issue a new access token. This improves security and avoids token misuse. Access token rotation (even when they are not expired) is preferred whenever possible.
Further, this fully agree to OAuth 2.0 rfc.
Refreshing an Access Token
If valid and authorized, the authorization server issues an access
token as described in Section 5.1. If the request failed
verification or is invalid, the authorization server returns an error
response as described in Section 5.2.

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

oauth2 spring-security should you be logged in before requesting a token or code

I'm trying to setup oauth2 using spring-security (2.0.3.RELEASE) in a spring-mvc application, with a grant type of password.
When executing the following request to access a token:
curl -X POST "http://localhost:8080/oauth/authorize?client_id=testclient&grant_type=password&username=user&password=test123&response_type=token"
I'm getting a:
org.springframework.security.authentication.InsufficientAuthenticationException: User must be authenticated with Spring Security before authorization can be completed.
When tracking down this exception I noticed it is originated at AuthorizationEndpoint.java line 137 wheren the code checks if the user is authenticated:
if (!(principal instanceof Authentication) || !((Authentication) principal).isAuthenticated()) {
I find this odd, should I first login and the post to the /oauth/authorize resource before trying to access the token ?
If so why ? I'm already adding my password and username to the /oauth/authorize request. I don't see the benefit of being logged in before trying to get a hold of a token if you must supply the password and username again ?

You are using the wrong endpoint. If you're using the password grant, you should be sending the request to the token endpoint. See the OAuth2 spec for details.

OAuth Authorized Access Token question for Java

I am developing an OAuth library to be used by BlackBerry mobile devices to connect to Netflix. I have successfully negotiated the request token and the access token. I have received the authorized token, the token secret, and the encrypted subscriber ID.
Encrypted subscriber ID:
T1BlCJtdcWMuF6gJEfue96_W.kZ_gW81h59KqLEfT1AzE-
Authorized Token: T1U.wMxbvP.KCdxGpqmfERA0y3BKEuyhYIljMF5W1k0iXD9j.2qDMw7NjoaOnG40UXESpqPk37gJbBlB1Ve.uatw--
I am now having trouble using the subscriber ID and the authorized token to retrieve the user information from Netflix. Does the authorized token look correct? It seems a little off to me as compared to the request token and unauthorized token....
I would appreciate any advice, thanks!

Those seem correct to me. Have you compared the request you're making to the one on http://developer.netflix.com/walkthrough? Are you making sure to use the oauth_token_secret returned from requesting the access_token (step 4 in the walkthrough), and not the one you got from request_token (step 1 in the walkthrough)?