Generating access tokens programmatically for OAuth Auth Code Grant Type

[API Dev]

We have an implementation of OAuth client credentials grant type for our application. We plan to extend it by support auth code grant type for a new rest api we plan to expose to our clients. Following this guideline we decided to implement authorization code grant type. The client of our web api would basically be a programmatic rest api client running as a standalone program. Since the auth code grant type flow involves a series of handshakes, how would it generate an access token to be used for making the api call? 

Do rest api's having auth code grant type authentication have programmatic clients? 

Thanks.

[Jørn Wildt]

> Do rest api's having auth code grant type authentication have programmatic clients?

Usually not. The authorization code grant flow typically involves a human in the flow that sign-in in order to obtain the authorization token that is later used to obtain the access code. But that sign-in could of course by done programmatically.

I have seen Windows implementations where a webserver uses Windows authentication credentials from its current user to sign-in for the authorization token on behalf of the user (basically simulating the redirect steps without a browser). In this case the user had logged in to the webserver earlier on (via Windows AD).

> Since the auth code grant type flow involves a series of handshakes, how would it generate an access token to be used for making the api call?

Could you please clarify "it" and "the api call" - who/which are you refering to?

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[API Dev]

Thanks for the reply.

Usually not. The authorization code grant flow typically involves a human in the flow that sign-in in order to obtain the authorization token that is later used to obtain the access code. But that sign-in could of course by done programmatically.

Right. A human involved in the flow is an important point. That clarifies my understanding on the grant type to chose for our client flows.

Could you please clarify "it" and "the api call" - who/which are you refering to?

Let me re-phrase the question - In case of a standalone client making a call to our api, my question was how would such a client generate the token when the server implements auth code grant type? 

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.

[Jørn Wildt]

> In case of a standalone client making a call to our api, my question was how would such a client generate the token when the server implements auth code grant type?

Take a look at the top most diagram here: https://docs.oracle.com/cd/E39820_01/doc.11121/gateway_docs/content/oauth_flows.html.

The client does not generate neither the authorization code nor the access token. Both are generated by the authorization server and returned to your client.

If your "standalone client" is not a webserver you can embed a browser in your client and let the user authorize through that. When the authorization server returns the authorization code through a redirect, your client app reacts to it and extracts the authorization code. Then it uses that to get the access token via a direct HTTP GET to the authorization server.

/Jørn

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

[Andrew B]

You could leave the client credentials grant in place alongside the auth code grant- use one for machines, one for humans.