This guide will give you an overview - without going into the technical details of the implementation - of the steps you have to go through if you want to login the User of your Provider on your website using Connect.
If you already know what the OAuth 2.0 Authorization Code Flow is about and you are looking for the technical implementation guide, you should consider one of the following links below:
Step 1: Register Provider and Application accounts
The first thing you have to do is to create a Provider account and an Application account which is associated with this Provider.
You can create multiple Application accounts and assign each account to different services or products you wish to use connect for.
|
Tip
|
As an example, you could have an Application account each for your Native mobile, Desktop and Website Applications |
Step 2: Add a link on your website to redirect the User to Connect
|
Note
|
If you plan to use this implementation on a Native Mobile Application, you should consider implementing the Authorization Code Flow with PKCE Extension, for better security. |
The next thing you have to do is to build the link that will redirect the User to Connect, so that we can handle the Authentication on your behalf.
You can put this link anywhere you want your Users to be able to login.
To build this link, you will need your client_id and your redirect_uri.
You should receive these credentials from your Provider, if you are not the one who completed step 1 above.
|
Important
|
If you’re on the web, this link should open on the same tab and window. It should not have a target="_blank" attribute.
|
Once a User has clicked this link, he or she will be redirected to Connect and will be able to login with his or her preferred Authentication method (phone, email or social login).
At this point, Connect will do the heavy lifting: you don’t have to do anything for the actual sign-in process.
|
Note
|
Please note that there is no specific Signup (i.e. Creation of a new User) process. From Connect’s point of view, it is just a first-time Signin. |
Step 3: The User gets back on your website, authenticated
Once your User has successfully logged in, Connect will redirect the User to your redirect_uri (that you provided in the Login link) with a query parameter in the url — something like:
|
Note
|
The redirect_uri is a route on your website that will be called by Connect as a GET HTTP request with an authorization_code as a query parameter.
|
|
Note
|
The redirect_uri can also be a custom scheme URI which is understood by your Native Application, in the case of Implementing Authorization Code Flow with PKCE Extension.
|
The authorization_code is a one-time token (like a receipt) that your server will need to exchange for an access token.
To exchange the received authorization_code for an access_token, you will need to send the following to Connect:
-
The
client_idandclient_secretthat you received from your Provider -
The
authorization_codethat you received on yourredirect_uri
You will then receive a response with an access_token.
|
Warning
|
As the name implies, your client_secret should stay… SECRET. It must be stored securely and you should never share it with anyone. You should never share your client_secret with your User’s Browser. This means that this process is NOT compatible with Single Page Applications (SPAs).
|
Signin worflows schemas
Without social login
Here a diagram describing the user signin workflow in a website using Connect:
With social login
If you want to integrate the social login (such as Facebook, Google or Github for example), the user may go through few more steps:
|
Note
|
To get more details about the email, phone number and scopes sections, please refer to the diagram in the section called Without social login.
|
