I'm trying to build an Oauth2.0 Authorization server and I wanted to understand more about the response_type and grant_type parameters.
From what I've read so far, response_type is a query parameter on the /authorize endpoint and it's values can be either 'token' or 'code' which indicates that the authorization server will respond with an access token or an authorization code.
grant_type is a query parameter on the /token endpoint which indicates which grant type will the authorization server use to either generate a token or a authorization code. Grant types can be 'authorization_code', 'client_credentials', 'implicit' etc.
My question is, how will the authorization server behave if I pick the response_type as 'token' but the grant_type as 'authorization_code' ? Since the authorization code grant is supposed to return a code and not a token, what is the server going to do in this scenario ?
Similarly, if I choose 'code' response type and 'implicit' grant type, what will be the behaviour ?
CodePudding user response：
The authorization code flow
(1) makes an authorization request to an authorization endpoint
(2) receives a short-lived authorization code
(3) makes a token request to a token endpoint with the authorization code
(4) gets an access token
The implicit flow
(1) makes an authorization request to an authorization endpoint
(2) gets an access token directly from the authorization endpoint.
So server will decide which flow by client's response_type in GET request.
The implicit flow is handy but it is high rick due to hacker easily get an access token. if Hacker change his own redirect URL, he can get access token. It called middle attack.
The authorization code flow with PKCE more secure due to code_chanllenge and code_verifier to makes double check
between client and auth server. It called Proof Key for Code Exchange (PKCE)
The server stored code_chanlllenge and code_challenge_mothod, then when ask a access_token, server verify
code_verifier by code_chanlllenge and code_challenge_mothod.
Also other two flows are exists password credentials flow and client credentials flow
References
Diagrams And Movies Of All The OAuth 2.0 Flows
Implicit Flow vs. Code Flow with PKCE
CodePudding user response：
I wanted to add a little here because I think the original poster was asking about a particular case and not the overall flows. I think it's a good question that the OAuth 2.0 spec doesn't explicitly address for this particular case.
How will the authorization server behave if I pick the response_type as 'token' but the grant_type as 'authorization_code'?
There's not really a good reason for this to happen. If a client uses response_type with token, and the client is following OAuth 2.0, that means the client is sending a request to the authorization endpoint. The authorization server redirects the user agent to do some kind of authentication and ask for authorization from the resource owner. If everything is successful, the client gets an access token. There's no need to then make another call to the token endpoint where the grant_type would be needed. The authorization server should see this as an entirely different request. If the client first makes a request to the token endpoint with the grant_type of authorization code (which isn't following the OAuth 2.0 flow), the authorization server should respond with an error because the client wouldn't have an authorization code to use with the code parameter.
grant_type REQUIRED. Value MUST be set to "authorization_code".
code REQUIRED. The authorization code received from the authorization server. 4.1.3
The authz server doesn't have a memory of what the client "did previously". What I mean is that, as you mentioned, response_type and grant_type are parameters used at different endpoints. So requests making use of these are separate. response_type for when sending to the authz endpoint and grant_type is used when sending a request to the token endpoint.
Something that the authz server does need to handle, and can be an easy mistake by the client, is if it receives a code parameter and a grant_type parameter with something like client_credentials as its value at its token endpoint. I don't think this part is explicitly addressed in the spec because code is more like an extraneous parameter, but I believe it falls under the invalid request error because you could consider it an "unsupported parameter" given that the grant_type in the request was client_credentials and the client credentials grant type does not support that parameter:
invalid_request: The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. 5.2