oauth[:scope]: The OAuth scope to use when requesting the OAuth
token. Default: identity.

allow_if: A lambda that takes an email address. If the lambda evaluates to
true, allow the user through. If false, redirects to redirect_url.
By default, all users are allowed through after authenticating.

allow_if_user: A lambda that takes the
account resource
representing the user. If the lambda evaluates to true, allow the user
through. If false, redirects to redirect_url. By default, all users are
allowed through after authenticating.

redirect_url: Where unauthorized users are redirected to. Defaults to
www.heroku.com.

expose_token: Expose the OAuth token in the session, allowing you to
make API calls as the user. Default: false

session_sync_nonce: If present, determines the name of a cookie
shared across properties under a same domain in order to keep their
sessions synchronized. Default: nil

allow_anonymous: Accepts a lambda that gets called with each
request. If the lambda evals to true, the request will not enforce
authentication (e.g:
allow_anonymous: lambda { |req| !/\A\/admin/.match(req.fullpath) }
will allow anonymous requests except those with under the /admin
path). Default: nil, which does not allow anonymous access to any
URL.

skip: Accepts a lambda that gets called with each request's env.
If the lambda gets evaluated to true, heroku-bouncer's middleware will
be completely skipped. Default: 'false', which applies heroku-bouncer
to all requests.

Keep in mind that this adds substantial security risk to your
application.

The API token is short-lived, and expires 8 hours after issue. Heroku provides
a separate refresh_token (available as bouncer.refresh_token) that can be
used to fetch fresh API tokens if necessary. See the
token refresh documentation
for details.

Logging out

Send users to /auth/sso-logout if logging out of Heroku is
appropriate, or /auth/logout if you only wish to logout of your app.
The latter will redirect to /, which may result is the user being
logging in again.

Security Model: A Tale of Three Secrets

There are three secrets in use:

A OAuth secret. Paired with the OAuth ID, this is how the Heroku
authorizes your OAuth requests with your particular OAuth client.

A bouncer secret. Bouncer encrypts and signs all user data placed in
the session. This ensures such data cannot be viewed by anyone but the
application.

A session secret. This is used to sign the session, which validates
the session was generated by your application. Strictly speaking,
however, this is outside of Bouncer and is not a part of its security
model.

In totality, Heroku Bouncer ensures session data can only be generated
and read by your application. However, they do not protect against
replay attacks if the data is obtained in its entirety. SSL and session
timeouts should be used to help mitigate this risk. CSRF tokens for any
actions that modify data are also recommended.