Skip to main content
Version: Python

API Authentication

This section provides information on how to authenticate with the different Glide services when using the raw HTTP APIs.

Understading the Different Authentication Methods​

Different Glide services use different authentication methods depending on the requirements of the service. To access a service API you need an access token, there are two types of access tokens:

Application Access Tokens​

This token authenticates the application itself and as such only requires a single request to obtain. This token is used to access the Glide API on behalf of the application itself (e.g. Magic Auth).

  • Client Credentials Flow: To get this kind of token you need to send a request with your client id and client secret requesting access to a specific service. This will return an access token that can be used to access the service API.

User Access Tokens​

This token authenticates a user and the application and as such requires a user to authenticate with Glide. This token is used to access the Glide API on behalf of the user. (e.g. Number Verify).

There are two ways to obtain a user access token:

  1. Authorization Code Flow: A flow where the user is redirected to Glide to authenticate and authorize the application, this authentication can happen silently if the user is making the request from their mobile device. The telecom operator will automatically authenticate the user and return to a pre-registerd redirect URL of your server with an authorization code. This code can then be exchanged for an access token by your backend.

  2. Backchannel Authentication: A flow where the user is authenticated by the telecom operator without the need for the user to interact with Glide. Your backend requests to initiate the authentication on behalf of the user and the telecom operator will authenticate the user check that no consent is required and return an auth_req_id. This auth_req_id can then be used to exchange for an access token. In the event that the user needs to consent you will also get back a consent_url which you can redirect the user to.

Scopes and Purposes​

When requesting an access token you can specify the scopes and purposes that the token will have. This is true for all flows, with client_crendentials you can specify the scopes in the /oauth2/token request, with authorization_code you can specify the scopes in the /oauth2/auth first request and with backchannel authentication you can specify the scopes in the /oauth2/backchannel-authentication request.

In each API reference you will find the scopes and purposes that are required to access the different endpoints. The format of a scope is:

dpv:<purpose>:<scope>

For example if you subscribed to sim-swap and registered that you want to use the api for FraudPreventionAndDetection you would use the scope dpv:FraudPreventionAndDetection:sim-swap.

You can also leave off the purpose and just use the scope sim-swap and the server will take your first registered purpose.

Authentication Reference​

The next section includes the raw HTTP API reference for the different authentication methods.