Having a custom login integration allows your users to sign in with credentials they also use for other environments. This article describes what the custom login and SSO are and how they can be set up.
What is custom login and SSO?
By default, your users will be able to sign in with their email addresses. They will then create an account on your Floq platform, which they have to confirm by clicking the link from the confirmation email they receive.
You can also choose to link your login system to the app, so that your users can easily sign in with credentials they already know. When signing in through the profile icon on the top-right, the user is redirected to your sign-in page. After a successful authentication, an account in our platform is created that is used to store all app-related user information, such as saved favourites or chat conversations. Users can then start using features that require a being signed in without having to confirm their email address.
To support custom login, we need you to send over the email address, first name and last name of the user after authentication. This information is used to create the account in our platform and will then be filled in in the user profile in the app already. Other information can then be manually added by the user. Please note that this information cannot yet be synced back to your system.
Using your custom login can allow for connecting our services to others you have using Single Sign-On (SSO). SSO is a mechanism that allows users to log in once and access multiple applications or services without needing to enter their credentials repeatedly. This means that when your users sign into the app, they can access links from the app to your website without having to sign in again. SSO works anywhere in the mobile and web apps, for example, on info tiles and event content. Please note that the user might have to confirm signing in by clicking a button, but their credentials are already filled in.
How to set it up
Further details for custom login need to be estimated by our development team and therefore discussed with your Customer Success Manager in advance.
When you use the well-known OAuth2 protocol, we can easily connect your login, using Authorization Code as the grant type method. Besides OAuth2 authentication, we can also offer connecting to a custom backend or external system. Since our platform will communicate with the external system when a user is authenticated, it needs to be available at any given moment before and during an event.
To develop a custom login, we need the endpoints as mentioned below, with clear documentation and credentials to set our callbacks and IPs. A testing API would be preferable, or credentials with the ability to set 'http://localhost' as callbacks for development purposes.
clientID: e.g. 'aclientid' and 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. An example of this redirect would be:
for development/test: https://eureka.dev.indrina.com/auth/oauth/LOGINNAME/callbackMobile, where LOGINNAME is replaced by the custom login name on our end
for production: https://backend.get-eureka.com/auth/oauth/LOGINNAME/callbackMobile.
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 at least an e-mail address, first name and last name, which we need to create the users in the Floq platform. This endpoint should be bearer token protected and can be accessed only with a valid access token per user.
To support Single Sign-On, your website needs to be capable of processing authentication tokens obtained through your authentication process/login. Those tokens can then be passed on in order to access-control content based on a specific user type or group.This can, for example, enable users to visit restricted areas on your website without having to login again.