Implement support for authentication
Calls from Reserve with Google to your backend need to be secured using SSL/TLS with certificate-based, mutual client/server authentication. This requires the use of a valid server certificate for your gRPC implementation and accepting a valid client certificate.
Server certificate: the partner server has to be equipped with a valid server certificate associated with the domain name of the server (refer to this list of accepted root CAs). GRPC server implementations expect to serve a certificate chain that leads up to the root certificate. The easiest way to accomplish this is by appending the intermediate certificate(s) provided by the partner's web host in PEM format to the server certificate (also in PEM format).
The server certificate is verified at connection time and self-signed certificates are not accepted.
Client certificate: in order to authenticate us (as Google) to the partner, we provide a client certificate issued by the Google Internet Authority G2 (CA certificate) with the following properties:
Connection attempts without this client certificate should be rejected by the partner server.
To validate the client certificate, the server relies on a set of trusted client root certificates. You can choose to obtain this set of trusted roots from an authority like Mozilla or install the set of roots currently recommended by the Google Internet Authority G2. In both cases, you may have to manually update the root certificates at times.
Implement the gRPC Health Checking Protocol
Implement the GRPC Health Checking
This protocol enables Google to monitor the backend status of your gRPC
implementation. The service
is part of the GRPC distribution. Following the GRPC naming convention, the name
of the service in the health check calls is
ext.maps.booking.partner.v2.BookingService for API v2, or
ext.maps.booking.partner.v0.BookingService for API v0. The health check should
run on the same URL and PORT as the other endpoints.
Be sure to check out our FAQs.