"A" and "D" Explanation: The authorization code is a temporary code that the client exchanges for an access token. The code itself is obtained from the authorization server, where the user gets a chance to see what information the client is requesting and approve or deny the request. The following parameters are used to make the authorization request. You should build a query string with the parameters below, appending it to the application’s authorization endpoint from its documentation. • client_id o The client_id is the identifier for your app. You will have received a client_id when you first registered your app with the service. • redirect_uri (optional) o The redirect_uri may be optional depending on the API, but it is highly recommended. This is the URL to which you want the user to be redirected after the authorization is complete. This must match the redirect URL that you previously registered with the service. • scope (optional) o Include one or more scope values (space-separated) to request additional levels of access. The values will depend on the particular service.

I think the answer is ‘A & D’

From the RFC: https://tools.ietf.org/html/rfc6749#section-4.1.1 So, I agree, A,D. (A) The client starts the flow by sending the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).

Refer to "Understanding the OAuth Flow of a Webex Teams Integration" in DevNet, you can find it as follows. 1. Make sure the following are ready: - Webex Teams user account email and password - Application Client ID - Application Client Secret - Application Redirect URI So I think, 'A & C' is the correct answer.

I changed my opinion. A & D is correct. As in the devnet example, the first step arguments are redirect URI, state, clientID and scope. the second step's arguments are secret, auth-token, and so on.

(A) The client starts the flow by sending the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied

In the RFC, there is no secret.

Refer to https://tools.ietf.org/html/rfc6749#section-2.3.1 It can be used for client credential method... Also, this is a Cisco test, so in my opinion the first reference should be DevNet.

It looks correct.

Selected Answer: AD A & D are correct. https://tools.ietf.org/html/rfc6749#section-4.1.1

Selected Answer: AD A and D https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type Here’s what each query parameter means: response_type=code - This tells the authorization server that the application is starting the authorization code flow. client_id - The public identifier for the application, obtained when the developer first registered the application. redirect_uri - Tells the authorization server where to send the user back after they approve the request. scope - One or more space-separated strings showing which permissions the application is requesting. The specific OAuth API you’re using will define the scopes it supports. state - The application generates a random string and includes it in the request. It should then verify that the same value is returned after the user authorizes the app. This is used to prevent CSRF attacks. client_id not name so E is incorrect

Selected Answer: AD C. secret that was generated by the authorization server when the application registered as an OAuth integration (client_secret): The client secret is a confidential credential used by the client to authenticate itself to the authorization server, but this is mainly used in the second step of the authorization code grant flow when the client exchanges the authorization code for an access token. It's not sent in the initial authorization request to the user.