It's useful for operators to classify users into separate groups which
we have termed "organizations". For other OAuth providers, the notion of
an organization typically fell along company lines. For example,
MegaCorp might have a "MegaCorp" GitHub organiztion, and all email
addresses would have the domain "megacorp.com".
Auth0 is slightly different in that MegaCorp would likely run their own
Auth0 provider for their internal services, so "organizations" in Auth0
are no longer synonymous with "large organizations" (or companies).
Instead, Auth0 organizations could be used to restrict access to
Chronograf instances based on team membership within an organization.
To make use of Auth0 organizations, operators should modify users'
app_metadata to include the key "organization". Its value should be the
organization which that user belongs to. This can be done automatically
through arbitrary rules using Auth0 Rules.
Auth0 is an OpenID Connect compliant OAuth2 provider, so we're able to
re-use the generic OAuth2 provider to implement it. The routes required
by Auth0 have been hardcoded for user convenience.
Also, Auth0 requires users to register a subdomain of auth0.com when
signing up. This must be provided to chronograf through the
`--auth0-domain` parameter (or `AUTH0_DOMAIN` ENV). This is **distinct**
from the `PUBLIC_URL`. For example, for a Chronograf hosted at
`http://www.example.com`, and an Auth0 domain of
`http://oceanic-airlines.auth0.com`, a client-id of `notpennysboat` and a
client-secret of `4-8-15-16-23-42`, the command line options would look
like:
```
chronograf \
--auth0-domain=http://oceanic-airlines.auth0.com \
--auth0-client-id=notpennysboat \
--auth0-secret=4-8-15-16-23-24
--public-url=http://www.example.com
-t `uuidgen`
```
Michael Desa
Tim Raymond
Jade McGough