Grant request instead of Implicit Flow + Walkthru about java-oauth-server

[TakahikoKawasaki]

Authorization Code Flow

Request To Authorization Endpoint

GET {Authorization Endpoint}
  ?response_type=code            // Required
  &client_id={Client ID}         // Required
  &redirect_uri={Redirect URI}   // Conditionally Required
  &scope={Scopes}                // Scopes, Space-delimited
  &state={Arbitrary String}      // Recommended
  HTTP/1.1
HOST: {Authorization Server}

Response From Authorization Endpoint

HTTP/1.1 302 Found
Location: {Redirect URI}
  ?code={Authorization Code}    // Always included
  &state={Arbitrary String}     // Included if the authorization request included 'state'.

Request To Token Endpoint

POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code  // Required
&code={Authorization Code}     // Required. The 'code' in the authorization response.
&redirect_uri={Redirect URI}   // Required if the authorization request included 'redirect_uri'.

Response From Token Endpoint

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"{Access Token}",    // Always included
  "token_type":"{Token Type}",        // Always included
  "expires_in":{Lifetime},            // Optional. Lifetime in seconds
  "refresh_token":"{Refresh Token}"   // Optional
}

[TakahikoKawasaki]

the implicit flow generates only a short living token and does not assign to the client a long living grant.

Not always. Access tokens issued by Implicit Flow can be long-lived tokens depending on the configuration of the authorization server. On the other hand, authorization codes issued by Authorization Code Flow are short-lived because 4.1.2. Authorization Response in RFC 6749 says as follows:

REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.

BTW,

Does your demo support the Grant+token interaction flow?

What is "Grant+token interaction flow"? RFC 6749 defines 4 authorization flows as listed below and I cannot understand what you mean by "Grant+token interaction flow".

1. Authorization Code Flow
2. Implicit Flow
3. Resource Owner Password Credentials Flow
4. Client Credentials Flow

Please see "Diagrams And Movies Of All The OAuth 2.0 Flows" to understand differences among the flows.

java-oauth-server already supports all the flows.

[ftarlao]

Thank you,
I have concluded from the diagrams that I was looking for the 'Authentication Code Flow' (.. is the one that I have learned during classes). From RFC I was not able to assign the label 'Authentication Code Flow' to the workflow I was looking at, I have thought it was the 'vanilla' one.
Now I (hopefully)have a clearer idea, I'll try to request a code 'grant' to your AS demo by following the RFC.
It would be nice to have any tips/examples, in your AS demo wiki, on how to consume the authorization endpoint in a 'Authorization Code Flow'.
Thanks for all explanations.
Regards