Skip to main content

Security Guidelines

Stitch takes the security and privacy of both its clients and end users seriously. However, certain mitigations require participation from integrating parties for these mitigating measures to be effective.

Please review the following list of security recommendations before you start integration, and again before the release of your application.

Keywords​

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119.

Guidance​

  • It is RECOMMENDED that Refresh and Access Tokens be stored in encrypted format at rest if stored on the server side.
  • If a token breach is detected, Stitch SHOULD be immediately contacted so that affected tokens can be revoked.
  • The number of employees with access to tokens SHOULD be minimized.
  • Scopes SHOULD only be requested if needed. This limits the potential for abuse should a breach remain undetected.
  • Redirect URIs MUST be present and MUST be protected by SSL and HSTS to prevent Man in the Middle Attacks.
  • The code_challenge and code_verifier MUST be regenerated for each authorization request.
  • The code_challenge MUST be between 43 and 128 characters in length.
  • The code_verifier MUST be between 43 and 128 characters in length.
  • The code_verifier MUST only contain the characters A-Z, a-z, 0-9, and the punctuation characters -._~ (hyphen, period, underscore, and tilde).
  • The unique, cryptographically secure, random nonce and state parameters MUST be used for each request.
  • The nonce parameter MUST be between 32 and 300 characters in length.
  • The state parameter MUST be between 32 and 300 characters in length.