Custom login, SSO, Profile Sync

Requirements to integrate your own login within your Conference Compass mobile and web apps.

This article describes the user experience and the technical requirements for custom login development, SSO, and Profile Sync. Reach out to your Customer Success Manager, if you are interested in having this custom development for your app.

User experience on the app

By default, your users will be able to sign in with their email addresses.

You can also choose to link your society's login system to the app. This way your members can easily sign in with the credentials they already know.

Users sign in through the profile icon on the top-right, both on the society level and within the event. When clicking Sign in, users are redirected to your OAuth sign-in page. If the sign-in succeeds, an account on our servers is created in the background and users can proceed using the chat, syncing their favourites, etc.

If a Profile sync is developed, fields in a user's profile are automatically filled in. Which fields should be synced, needs to be defined when sharing the technical information with Conference Compass (see below under profile requirements).

Technical requirements for custom login

Conference Compass offers custom sign-in possibilities that are based on the well-known OAuth2 protocol, using authorization code as the grant type method.

Besides OAuth2 authentication we can also offer custom development for other authentication methods. Custom authentication development requires a client to provide their own backend or external system that handles the authentication. Our event platform will then communicate with that system when a user is authenticated. This means the system has to be available at any given moment before and during an event.
Further details for custom authentication need to be estimated by our development team and therefore discussed with your Customer Success Manager in advance.

Custom login requirements

• Documentation, Endpoint addresses, and credentials to set our callbacks and IPs

• Testing API would be preferable or credentials with the ability to set 'http://localhost' as callbacks for development only

• We also support grant type 'password' oAuth2. The Password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.

• clientID: e.g. 'aclientid'

• clientSecret: e.g. 'yhgfyefg46fg47ft47fv4vc647fvg47fv'

• authorizationURL: e.g. 'https://myhost/oauth2/authorize.php'. This is the basic login URL, which redirects to our server after a successful login. The redirect path receives a code that exchanges for a token at this link. Additional information like redirect URL, clientID, and more are added as query data on the URL.

• tokenURL: e.g. 'https://myhost/oauth2/token.php'. Here we exchange the code for a valid access token.

• host: e.g. 'your_host'

• profilePathURL: e.g. '/oauth2/profile.php'. We usually ask for a user information endpoint with an e-mail address, first name, last name, and a type of identifier, like an ID, which we need to create the Eureka users. This endpoint should be Bearer token protected and can be accessed only with a valid access token per user.

After a successful OAuth2 authentication, an account is automatically created and given a random password. This account is used to store all app-related user information, such as saved favourites or chat conversations.

Technical requirements for SSO

Please note: this development requires a custom login.

Based on the supported authentication methods, our apps can offer single sign-on (SSO) access for web-based content.

With SSO, users can access content that is accessible only to authenticated users without an additional step of signing in which would otherwise be part of that web page. This is done through the web browser within the app that propagates authentication information to web pages that a user visits once he has signed in.

To support our SSO solutions, your website needs to be capable of handling and persisting authentication cookies.

The SSO works anywhere in the mobile and web apps, for example, on info tiles and event content. If the user accesses a page that requires signing in, the SSO will automatically sign the user into the mobile or web app.
Please note that the user will have to trigger/confirm that by clicking the sign-in button, but their credentials are pre-filled in.

Technical requirements for ProfileSync

Please note: this development requires a custom login.

ProfileSync is the primary way to get the user profile fields updated not only on sign-in but also when opening the event and the user profile, this means the profile of a user is kept in sync. Updated fields are marked as imported and cannot be edited by the user on the event platform, if a user wants to update these fields, he needs to do this in the original user database and go back to the event platform to sync the changes.

The refresh token mechanism is supported, the Refresh Token grant type is used by exchanging a refresh token for an access token when the access token has expired. This allows clients to continue to have a valid access token without further interaction with the user and can be used for example to get a new authentication token for the profile synchronisation.

Further details for profileSync need to be estimated by the development team, and therefore you should discuss it with your Customer Success Manager.

ProfileSync Requirements

• Working API with clear documentation and credentials

• A list of user data to import according to our supported fields (email, first, and last name are mandatory) including groups or extra logic for creating groups and adding/removing users. The group indication must be included in the same call. 

In the table below, you can find the supported profile fields on the Conference Compass platform. Use the second column to map with fields in your data.