Introduction
Some organizations have existing websites or internal computer systems that are used by their members to manage their accounts. Your members may already have login credentials, and you want them to be able to use these same login credentials when registering, purchasing tickets, or setting up their event profile within Grenadine websites.
If your login mechanism supports oauth, Grenadine can set up your Admin to connect to your authentication provider. This will enable your user to use the same user/password on Grenadine websites as they do when logging in to your own corporate systems.
If your authentication provider supplies metadata (such as an employee number, student number, member number), Grenadine may also be able to fetch those metadata at login time, to insert into a metadata field of the person profile.
Note: Custom login is an enterprise feature and may involve extra costs in setup or development.
How It Works
By default, Grenadine offers several ways to attendees and speakers to identify yourself. These include:
- Login with Facebook
- Login with Google
- Login with Grenadine email/password
- Login with Grenadine Magic Link
When we set up your custom login provider, your organization’s login will be presented as an additional choice when people wish to log in. For example, here is a screenshot of an event website that allows for Facebook, Google, and Grenadine login, in addition to a university’s custom login provider (Concordia University in this example):
You can decide which login providers to enable in the Grenadine community configuration screen available in Grenadine Admin -> Event settings > Website. If desired, you could enable only your own login mechanism and disable all other options.
What Information We Need from You
If your environment has an OAuth2 provider for authentication it is possible to integrate that with Grenadine so that people using the generated sites can log in with their credentials from your system.
There may be some differences between OAuth providers in the names and types of parameters used when configuring them. You will need to coordinate with the Grenadine development team to set up your OAuth login.
To enable this, you will need to coordinate with our development team. The information that we would need consists of the following:
| Endpoint | This is the URL for your OAuth server |
| Key/Client ID | A key for our application when accessing your OAuth server |
| Secret | The secret for our application |
| Scopes (if applicable) | If any OAuth scopes are applicable |
Grenadine will also pass a state parameter when initiating the OAuth request. We expect this state parameter to be returned to us as per the OAuth2 specification.
Often the OAuth server needs to know the origin and redirect endpoints.
| Authorized Origin | Authorized Redirect | |
|---|---|---|
| staging | https://next.grenadine.co | https://next.grenadine.co/sites/auth/{service_name}/callback |
| production | https://sites.grenadine.co | https://sites.grenadine.co/sites/auth/{service_name}/callback |
Note: The {service_name} will be the name that we use to identify your OAuth service.
As well as passing back the authentication and refresh tokens in the response. The Authhash will return the following:
- provider – the name of the provider as a single string (usually the same as {service_name})
- uid – the UID for the person logging in in your system
The info hash returned from the provider should contain the following variables:
- first_name – the first name of the person logging in
- last_name – the last name of the person logging in
- email – the email of the person logging in
and optionally:
- image – the image of the person logged in (this would be a public URL to an image)
- name – the full display name of the person logged in