K2 outbound authentication: Google OAuth2

3 Mins. Read.
Note2Self

This article explains how you can setup outbound authentication towards google’s API’s. You would need this when you want to use a service broker to connect to one of google’s many API’s.

Resource Type

A resource type within K2 is template for an Oauth configuration. You can find them under Management > Authentication > OAuth > Resource Types. For Google you’ll have to add a new Resource Type. The Resource Type will have Parameters. These parameters are used during the OAuth flow. The checkboxes configure when the parameters are being used. You can also specify default values for the parameters, do this for values that don’t change per Resource. A good example of a resource parameter is the scope parameter for google. If you have a JSSP broker for google drive, then you could make a Resource for Google Drive and provide the scope for that in that resource. If you’d have another JSSP broker (eg. google sheets) then you can use another Resource for that with a difference scope. The Resource Type has default values, and those can be overwriten at the Resource level.

Parameter usage

As indicated, the parameters have checkboxes that tell K2 when the parameter should be send out, or is expected to be received. If a parameter is received, then the value is stored and used in later calls. In an oversimplified diagram, this is how the OAuth flow works:

OAuth diagram

The parameter that you check, will be used in the request. So as example:

  1. If you check the Authorization Request checkbox, than that parameter will be added in the initial authorization request (step 1)
  2. If you check the Authorization Response checkbox, than these parameters are expected in the Authorization response (step 5)
  3. If you check the Token Request checkbox, than the parameters will be used in the Token request. Please note that the K2 server makes this request, not the browser (step 7)
  4. The response to this token request is indicated with the Token Response checkbox. You’ll typically see access_token in there and expires_in.
  5. If the access_token is not valid forever, then the refresh token allows you to retrieve a new access_token. K2 uses the parameters checked with the Refresh Token. The response should be the same Token Response.

Within the Resource you have different endpoints, which is also why there are 3 different endpoints in the diagram. If you only provide the authorization endpoint then it will be used for all requests.

If you want to know more about Oauth, then please see https://tools.ietf.org/html/rfc6749. It is a large document and not easy to read, but of course a great reference. There are many customers that i’ve pointed to this RFC! Google themselves also have [https://developers.google.com/identity/protocols/oauth2](some great documentation on Oauth).

Google specifics

Because K2 is a application server, we’ll be using the [https://developers.google.com/identity/protocols/oauth2/web-server](Using OAuth 2.0 for Web Server Applications). This allows the K2 server to use the user’s Oauth token, and also get new access tokens whenever that’s needed. The document linked actually provides all details around the parameters that are needed, but it’s easier to show screenshots and/or the table format.

Resource Types

Parameter|Authorization Request|Authorization Response|Authorization Defailt|Token Request|Token Response|Token Default|Refresh Request|Refresh Default —|—|—|—|—| token_type| | | | | expires_in| | | | | include_granted_scopes| | | | |