OAuth 2.0 for Server to Server Applications: two or three parameters? (Or: Can some Google engineers possibly not count up to three? :)

Question

I'm trying to obtain an Google OAuth 2.0 access token for a service account but receive an invalid_grant error instead. I've checked my various artifacts (private key, etc.) and clock timings but have not been able to resolve this so far.

There is one possibly related item that seems odd: Google's documentation says

Three parameters are required in the HTTPs POST, and these are shown below

This is followed by a table with two rows that specifies two parameters (grant_type and assertion). Could it be that a third is also needed (I've seen examples that also use assertion_type in some fashion)? Could it be that (some) Google engineers (or perhaps yours truly) cannot count up to three? :)

In summary: What are the appropriate parameters? It seems unclear from Google's current documentation.

UPDATE: Here is some further information: I can't use the Google API Client Library, because my application requires a language other than those currently not supported by Google. Therefore I have to implement the logic for creating and signing JWTs, etc., as is normally discouraged. I have confirmed that my service account artifacts are in order: I can use them with the Google APIs Client Library for Java to access the same calendar (from another than my target platform, i.e.). In particular, my "client_id" is of the form "...@developer.gserviceaccount.com" and my key is a 128-bit RSA private key, both as obtained from the Google APIs Dashboard.

Answer 1

I've now been able to confirm that it's two parameters, not three. Google's documentation seems to be correct insofar as it names those two parameters (grant_type and assertion) but wrong insofar as it refers to them as three parameters.

Evidence for two parameters comes from a current Internet-Draft (JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0), which defines an extension grant type under RFC 6749 (The OAuth 2.0 Authorization Framework).

Evidence also consists of having tried a verbatim access token obtained by the Google APIs client library (and revealed by logging) inside my (non-Java) implementation: use of this access token has made the invalid_grant error go away.

(There now evidently a problem about forming a SHA256withRSA signature left in my code, but that's another issue ...)