Configure PlaceOS Auth Source for Google


  • PlaceOS BAckoffice Administrator Access

  • client_id and secret obtained from Google.


  1. In PlaceOS Backoffice navigate to the Domains tab.

  2. Select the domain you would like to add Microsoft Authentication to.

  3. Click the Authentication Tab.

  4. Identify the OAuth Source previously created.

  5. Click the Edit Icon.

  6. Update missing fields per the table below

Configuring fields

These fields are specific to the OAuth2 provider and tend to differ slightly between providers.

Details on how Google handles OAuth2 will be used to describe the following fields

  • name: a friendly name for this authentication configuration

  • client_id: the id provided by the OAuth2 provider when you added a new application

  • client_secret: as above

  • site: the URL of the application requesting access ( in the screenshot above)

  • scope: the scopes, space separated, for the APIs that are intended to be accessed

  • token_method: POST or GET, Google uses a POST to obtain a token

  • authentication_scheme: do we use request params or request body to obtain a token, Google uses the body

  • token_url: the URL to obtain a token from, Googles is

  • authorize_url: this is the URL that initialises the OAuth2 request. Google details here.

  • user_profile_url: the is is the URL we can use to test the OAuth2 token and obtain user details

  • info_mappings: this maps PlaceOS fields to User Profile fields

  • authorize_params: query params to pass along with the authorize URL

  • ensure_matching: authorization response fields that should match

Google Example

An example configuration that works with Google

  • scope: profile email




  • token method: POST

  • Auth Scheme: Request Body

  • Info Mappings: (PlaceOS -> Google)

    • email -> email

    • first_name -> given_name

    • last_name -> family_name

    • uid -> sub

    • image -> picture

    • access_token -> token

    • refresh_token -> refresh_token

    • expires -> expires

    • expires_at -> expires_at

  • Authorise Params

    • access_type -> offline (this will return a refresh token)

    • prompt -> consent (ensures we are always sent a new refresh token on login)

  • Ensure Matching

    • hd -> (typically the domain after the @ in your login name)

The above stores a refresh token against each user for scoped directory access. A simpler version if token based access isn't required could be:

Last updated