This guide details how to integrate Mobile Connect into your .NET applications using the Mobile Connect SDK for .NET. It is strongly recommended that you read through this guide and familiarise yourself with the functions the SDK provides before downloading a demo app and starting to code.

The guide describes the processes for:

Prerequisites

Before you can make calls to Mobile Connect, you must have registered for a Mobile Connect user account and registered an application. This will provide you with your developer credentials, which you will need to specify in a configuration object, and your Application Short Name, which is a required parameter when calling the Authorization or Identity endpoints.

Configuring your Project

Use NuGet to add the Mobile Connect framework to your .NET project.

  1. In the Solution Explorer, right-click the project and select Manage NuGet Packages… The NuGet Package Manager opens.

    Manage NuGet Packages... screenshot

  2. On the Browse tab (which may be named Online depending on your installation) search for “GSMA MobileConnect”. The Mobile Connect SDK should be the only search result.

    NuGet Package Manager screenshot

    Select the Mobile Connect package and click Install. NuGet installs the SDK and all dependencies into the project.

Back to top

Using the SDK with Mobile Connect

The Mobile Connect SDK for .NET automates much of the basic housekeeping and configuration tasks of your application’s integration with Mobile Connect. Many of these functions activate in the Discovery phase, independently of the Identity Gateway endpoint your application will ultimately call, and so are described here for your reference.

Provider Metadata

A successful call to the Mobile Connect Discovery endpoint returns the end user’s Mobile Network Operator (MNO) and describes the Mobile Connect services that MNO supports, via a URI to the MNO’s Provider Metadata. The metadata describes the Identity Gateway endpoints (Mobile Connect services) your application or service can use and how those endpoints are configured – for example, the response types an endpoint can return, the subject identifier types supported, or the Identity Services encryption algorithms in use.

Although Provider Metadata is the primary source of information detailing the Identity Gateway configuration, it does not change often, so a cached version can be used without risk of expired data causing errors. The Mobile Connect SDK handles both the querying of the Provider Metadata and the caching.

  • If the Provider Metadata URI returns no data, the cached metadata is used.
  • Where the cached data is out of date (defaulting to 15-minute intervals) a subsequent query of the URI is attempted, and in the event of a second failed response, expired cached data is used.
  • Should neither the cached data nor the Provider Metadata URI return data (such as an error upon first user login) default values are used.

Regardless of the source, the SDK parses the Provider Metadata into a discrete list of properties. See the OpenID Provider Metadata definition for a list of the metadata available, although you should note that Mobile Connect's implementation may not be exhaustive.

The ProviderMetadata object is available on DiscoveryResponse.ProviderMetadata.

Back to top

Supported Services

Before your application or service can call an Identity Gateway endpoint (scope), you need to know if the MNO supports the scope you are calling. The Mobile Connect SDK provides the method isMobileConnectServiceSupported(String scope) in the discoveryResponse, which can be accessed as follows:

bool supported = discoveryResponse.IsMobileConnectServiceSupported(“mc_authz mc_identity_signup”)

The method accepts a comma- or space-separated list of scopes, which it then checks against the list of supported scopes in the Provider Metadata.

  • If all of the scopes passed as arguments are present in the Provider Metadata, the function returns true.
  • If any of the passed scopes are not present in the metadata, the function returns false.
  • If the Provider Metadata is not available, or the scopes attribute is missing, null, or an empty string, the function returns an exception: “Provider Metadata scopes unavailable”.

Back to top

Version Compatibility

Although the MNOs may support differing versions of the Mobile Connect APIs, the SDK automatically detects the version in use at an Identity Gateway from the Provider Metadata, and ensures that the correct Mobile Connect Profile is used when making calls to the Mobile Connect APIs.

Back to top

Application Short Name

The application you register with the Mobile Connect Developer Portal includes an Application Short Name, which is stored in the API Exchange and returned in responses from the Discovery service. The SDK captures the returned applicationShortName and includes it when constructing calls to the Mobile Connect Authorization and Identity endpoints. Following a successful call, the Application Short Name is displayed to the end user to identify the application requesting either authorization for a transaction or permission to share their user information.

Back to top

Mobile Connect Constants

The SDK provides a number of constants for referencing the Mobile Connect services by scope. They are available at GSMA.MobileConnect.MobileConnectConstants, and can be called using the following syntax:

GSMA.MobileConnect.MobileConnectConstants.MOBILECONNECTIDENTITYPHONE

The above example calls the scope "openid mc_identity_phonenumber". You can pass multiple scopes as a space-separated string; the SDK will remove any duplicates before making the call to the Identity Gateway.

The following constants are available:

Mobile Connect Product Constant Identifier Literal Value
Authentication (v1.0) MOBILECONNECT "openid"
Authentication (v1.1) MOBILECONNECTAUTHENTICATION "openid mc_authn"
Authorization MOBILECONNECTAUTHORIZATION "openid mc_authz"
Identity: Phone Number MOBILECONNECTIDENTITYPHONE "openid mc_identity_phonenumber"
Identity: Signup MOBILECONNECTIDENTITYSIGNUP "openid mc_identity_signup"
Identity: Signup Plus* MOBILECONNECTR3IDENTITYSIGNUPPLUS "openid mc_identity_signupplus"
Identity: National ID MOBILECONNECTIDENTITYNATIONALID "openid mc_identity_nationalid"

*This constant is available to support possible future products.

Back to top

Login Hint Support

You have the option to provide the login hint to the Identity Gateway in one of three formats: MSISDN, encrypted MSISDN, and PCR. Your decision on how to provide the login hint is governed by two factors:

  • The login hint formats supported by the Identity Gateway.
  • Whether you are a “Trusted Service Provider”; an unencrypted MSISDN is only accepted from a trusted provider – attempting to send one if you are not trusted returns an error.

The Mobile Connect SDK provides functions to test for login hint support in the Identity Gateway, namely:

  • IsLoginHintMSISDNSupported
  • IsLoginHintEncryptedMSISDNSupported
  • IsLoginHintPCRSupported

Each function checks the login_hint_methods_supported attribute in the Provider Metadata returned from the Discovery endpoint. Should the attribute be missing, the function checks the Mobile Connect Profile version supported; only version 1.2 supports passing the PCR as the login hint.

Once you have decided how to provide the login hint, the SDK offers a further three functions to build it for you:

  • GenerateLoginHintMSISDN(String MSISDN)
  • GenerateLoginHintEncryptedMSISDN(String encryptedMSISDN)
  • GenerateLoginHintPCR(String PCR)

Back to top

id_token Validation

A successful response from the Identity Gateway includes an id_token – a JSON Web Token, which validates against a JSON Web Keyset (JWKS), available at a URL specified in the Provider Metadata attribute jwks_uri.

The SDK performs a number of automatic validation actions to ensure the integrity of the response source, such as checking whether the token has expired. It also fetches the data from the jwks_uri location and stores it alongside the associated Discovery response, where it is cached. The following functions are then available to you to support id_token validation:

  • CheckIDTokenSignature(id_token) verifies the signature of the id_token based on the jwks_uri data. A successful validation returns true; a failed validation returns false; a missing JWKS certificate returns an error.
  • ReturnAllJWKSEntries allows you to fetch all of the keys from the JWKS data.
  • ReturnMatchingJWKSEntries allows you to fetch specific keys matching the following parameters:

    • kty – key type (e.g. RSA)
    • alg – algorithm (e.g. RS256)
    • use – sig (signature) or enc (encryption)
    • kid – key identifier

Back to top

Using Mobile Connect Authentication

The SDK allows you to call a method that accepts a reference to a configuration file as a parameter. With your developer credentials specified in the configuration file, you have everything you need to make a successful call to the Mobile Connect Discovery endpoint, and the methods AttemptDiscoveryAsync, AttemptDiscoveryAfterOperatorSelectionAsync, and HandleUrlRedirectAsync do just that, building and making the call, and then handling the response. The SDK also takes care of caching the response for re-use in a subsequent call – subject to the configured timeout. Once the end user has entered their MSISDN or specified their operator, and a successful Discovery response is received, the SDK builds the call to the Authentication endpoint. A successful authentication returns an id_token containing the user’s PCR, which is unpacked and available for verification against your user register.

The Mobile Connect SDK for .NET supports both client and server applications.

Client Application

The following procedure details how to add Mobile Connect Authentication to a client application.

Note: Mobile Connect supports synchronous and asynchronous methods; it is recommended to use the asynchronous form wherever possible.

  1. In Microsoft Visual Studio, create a new project based on a Windows 8 application template.
  2. In the MainPage.cs file, create a config object based on your developer credentials.

    Note: if you operate in the EU then you should use EU Discovery Service domain: eu.discover.mobileconnect.io

    MobileConnectConfig _config = new MobileConnectConfig
            {
                ClientId = "<yourClientId>",
                ClientSecret = "<yourClientSecret>",
                DiscoveryUrl = "<yourDiscoveryUrl>",
                RedirectUrl = "<yourRedirectUrl>",
            };
  3. Set up a Mobile Connect object.

    MobileConnectInterface _mobileconnect;
    
            private string _state;
            private string _nonce;
            private DiscoveryResponse _discoveryResponse;
    
            public MainPage()
            {
                this.InitializeComponent();
    
                _mobileconnect = SetupMobileConnect(_config);
            }
    
         private MobileConnectInterface SetupMobileConnect(MobileConnectConfig config)
            {
                IDiscoveryCache cache = new ConcurrentDiscoveryCache();
    
                return new MobileConnectInterface(config, cache);
            } 
  4. Add a method to generate a value for _state and _nonce when called..

    Note: GenerateSecureNonce() is a method of the Security helper class provided in the SDK.

                private string GenerateUniqueString()
            {
                return Security.GenerateSecureNonce();
            } 
  5. Define a button to start the Mobile Connect process with a call to the Discovery endpoint.

    private async void MobileConnectButton_Click(object sender, RoutedEventArgs e)
            {
                MobileConnectStatus status = await _mobileconnect.AttemptDiscoveryAsync(null, null, null, new MobileConnectRequestOptions());
    
                await HandleMobileConnectStatus(status);
            }
  6. In the UI definition file MainPage.xaml, add a button to call the method MobileConnectButton_Click() defined in the previous step.

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
            …
            <Button Content="MobileConnect"
                    Click="MobileConnectButton_Click"
                    HorizontalAlignment="Center"/>
            …
    </Grid>
  7. Still in the UI definition file, add a webview to display the URL response from Mobile Connect.

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
            …
            <WebView x:Name="web"
                     Grid.Row="2"
                     NavigationStarting="web_NavigationStarting"/>
        </Grid>
  8. Back in the MainPage.cs file, create a method handler to capture responses from Mobile Connect. The following handler captures both the OperatorSelection response and the Authentication response (the stage at which the user enters their phone number).

    private async Task HandleMobileConnectStatus(MobileConnectStatus status)
            {
                if(status.ResponseType == MobileConnectResponseType.OperatorSelection || status.ResponseType == MobileConnectResponseType.Authentication)
                {
                    web.Navigate(new Uri(status.Url));
                }
    }

    This handler uses the webview you created to display the requested URL for user interaction.

  9. Add a method handler to determine whether to load a response URL into the webview.

    private async Task HandleRedirect(Uri url)
            {
                // Allow the Mobile Connect service to handle redirected url
                MobileConnectStatus status = await _mobileconnect.HandleUrlRedirectAsync(url, _discoveryResponse, _state, _nonce);
                await HandleMobileConnectStatus(status);
            }
    
            private async void web_NavigationStarting(WebView sender, WebViewNavigationStartingEventArgs args)
            {
                // Handle the requested URL if it is the configured redirect URL
                if (args.Uri.AbsoluteUri.StartsWith(_config.RedirectUrl))
                {
                    // Cancel navigation to prevent final redirect from loading; navigate to blank to prevent previous redirect reloading
                    args.Cancel = true;
                    sender.Source = new Uri("about:blank");
                    await HandleRedirect(args.Uri);
                }
            }
  10. Add a clause to HandleMobileConnectStatus to capture the response from the Discovery endpoint, and to store that response for when building the call to the Authentication endpoint.

    private async Task HandleMobileConnectStatus(MobileConnectStatus status)
            {
                If…
    		…
                }
                else if(status.ResponseType == MobileConnectResponseType.StartAuthentication)
                {
                    _discoveryResponse = status.DiscoveryResponse;
                    // Generate state and nonce to be used for response validation
                    _state = GenerateUniqueString();
                    _nonce = GenerateUniqueString();
    
                    MobileConnectStatus newStatus = _mobileconnect.StartAuthentication(_discoveryResponse, _discoveryResponse.ResponseData.subscriber_id, _state, _nonce, new MobileConnectRequestOptions());
                    await HandleMobileConnectStatus(newStatus);
                }
            }
  11. Add another clause to capture the returned id_token (available through status.TokenResponse.ResponseData).

         private async Task HandleMobileConnectStatus(MobileConnectStatus status)
            {
                If…
                …
                else if(status.ResponseType == MobileConnectResponseType.Complete)
                {
                }
         }
  12. Finally, add an error handler to print returned errors. Add a text field into the UI definition file.

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
            …
            <TextBlock x:Name="errorText"
                       Grid.Row="1"
                       HorizontalAlignment="Center"
                       Foreground="Red"/>
            …
        </Grid>

    In MainPage.cs, add a final clause to the HandleMobileConnectStatus method.

    private async Task HandleMobileConnectStatus(MobileConnectStatus status)
            {
                If…
    		…
                else if (status.ResponseType == MobileConnectResponseType.Error)
                {
                    errorText.Text = status.ErrorMessage;
                }
            }

Back to top

Server Application

The following procedure details the steps for creating a server application capable of calling, and handling the responses from, the Mobile Connect services. The steps don’t describe how to construct the web pages that will be needed for a client to interact with the server application beyond describing the interfaces. In order to build and test the application described, create pages using your preferred scripting language to interact with the server application.

Note: Mobile Connect supports synchronous and asynchronous methods; it is recommended to use the asynchronous form wherever possible.

  1. In Microsoft Visual Studio, create a web project with Web API and a dependency injection library installed.

    Note: for this example, Ninject is used as the dependency injector. Where required, substitute the instructions provided with those applicable to your chosen tools.

  2. Create a Mobile Connect Configuration within the Ninject file. Set up dependencies using the Mobile Connect Web Interface.

    private static void RegisterServices(IKernel kernel)
            {
                MobileConnectConfig config = new MobileConnectConfig
                {
                    ClientId = "yourClientId",
                    ClientSecret = "yourClientSecret",
                    DiscoveryUrl = "yourDiscoveryURL",
                    RedirectUrl = "yourRedirectUrl",
                    XRedirect =  "yourXRedirect"
                };
    
                kernel.Bind<MobileConnectConfig>().ToConstant(config);
                kernel.Bind<ICache>().To<ConcurrentCache>();            
                kernel.Bind<MobileConnectWebInterface>().ToSelf().InSingletonScope(); 
    }
  3. Create a Mobile Connect controller.

    1. In the Solution Explorer, right-click your project and select Add > Controller…

    2. Select the type Web API 2 Controller – Empty and name it MobileConnectController.cs. The new controller file is created and opened.
    3. In the file, add a controller definition.

      [RoutePrefix("api/mobileconnect")]
          public class MobileConnectController : ApiController
          {
            private MobileConnectWebInterface _mobileconnect;
      public MobileConnectController(MobileConnectWebInterface mobileconnect)
              {
                  // Dependency injection will handle the passing of the mobileconnect argument
                  _mobileconnect = mobileconnect;
              }
      }
  4. Add a response handler.

    private IHttpActionResult CreateResponse(MobileConnectStatus status)
            {
                var response = Request.CreateResponse(HttpStatusCode.OK, ResponseConverter.Convert(status));
              
                if (status.SetCookie != null)
                {
                    foreach (var cookie in status.SetCookie)
                    {
                        response.Headers.Add("Set-Cookie", cookie);
                    }
                }
    
                // Wrap in a standard .Net Response Object
                return new ResponseMessageResult(response);
            }

    MobileConnectStatus is a large object, which needs to be condensed into a smaller response that can be easily JSON serialised and returned to the client. This is the role of the ResponseConverter, which returns a MobileConnectWebResponse. Each response has the action property, which contains a key specifying what the client’s next action should be, from the following list: “discovery", "operator_selection", "start_authentication", "authentication", "complete", and "error".

    During the Mobile Connect process, the Mobile Connect endpoints may set cookies. The if… statement passes any cookies back to the client as part of the response.

  5. Add a route “start_discovery” to call the Mobile Connect Discovery service.

    [HttpGet]
            [Route("start_discovery")]
            public async Task<IHttpActionResult> StartDiscovery()
            {
                // This method is called when the client makes an HTTP GET request to the relative url api/mobileconnect/start_discovery
    
                MobileConnectStatus status = await _mobileconnect.AttemptDiscoveryAsync(Request, null, null, null, true, new MobileConnectRequestOptions());
                return CreateResponse(status);
    
                // Return JSON to the client, similar to:
                // { "status": "success", "action": "operator_selection", "url": "http://discoveryurl.com/operator-selection" }
                // The client should access the url to allow the user to complete operator selection
            }

    Note: MobileConnectRequestOptions enables optional query parameters in the API.

  6. Add a handler to capture the parameters from redirected URLs containing the results of calls to both the Discovery and Identity Gateway endpoints. The client must forward the redirected URL’s parameters, as appropriate, using a GET action (see the code comments for the URL structure).

    [HttpGet]
    [Route("")]
    public async Task<IHttpActionResult> HandleRedirect(string sdksession = null, string expectedState = null, string expectedNonce = null)
            {
    // This method is called when the client makes an HTTP GET request to the relative url /api/mobileconnect
    // Expected calls:
    // After Operator Selection: http://hostname.com/api/mobileconnect?mcc_mnc=101_01&subscriber_id=1cf21232hzakxzkjxakjw....
    // After Authentication: http://hostname.com/api/mobileconnect?code=12345676424567432&sdksession=a54asdasgdasx67&expectedState=state&expectedNonce=nonce (state and nonce from start_authentication response)
    
                MobileConnectStatus status = await _mobileconnect.HandleUrlRedirectAsync(Request, Request.RequestUri, sdksession, expectedState, expectedNonce);
                return CreateResponse(status);
    
    // The response to the client will depend on the input. The following will be responses to the above expected calls
    // After Operator Selection: { "status": "success", "action": "start_authentication", "sdkSession": "a54asdasgdasx67", "subscriberId": "2g131jh2312h...." } (sdkSession should be stored and passed into subsequent requests in the process)
    // After Authentication: { "status": "success", "action": "complete", "token": { token_data } }
            }
  7. Add a call to the Mobile Connect Authentication endpoint, including values for state and nonce.

    Note: GenerateSecureNonce() is a method of the Security helper class provided in the SDK.

    [HttpGet]
            [Route("start_authentication")]
            public async Task<IHttpActionResult> StartAuthentication(string sdksession = null, string subscriberId = null)
            {
                // This method is called when the client makes an HTTP GET request to the relative url api/mobileconnect/start_authentication
                // Expected call: http://hostname.com/api/mobileconnect/start_authentication?sdksession=a54asdasgdasx67&subscriberId=1cf21232hzakxzkjxakjw....
                string state = GenerateUniqueString();
                string nonce = GenerateUniqueString();
    
                MobileConnectStatus status = await _mobileconnect.StartAuthentication(Request, sdksession, subscriberId, state, nonce, new MobileConnectRequestOptions());
                return CreateResponse(status);
    
                // This returns JSON to the client similar to the following
                // { "status": "success", "action": "authentication", "url": "http://authenticationurl.com/auth?param=x....", "state": "state", "nonce": "nonce" }
                // The client should access the url and store the state and nonce returned for later use
            }

    A successful call returns a URL, to which the client must be navigated. Once the user completes their interaction with the target page, the client is redirected. The client must forward the redirected URL’s parameters, as appropriate, using a GET action to the redirect handler route. This results in a final response from the Identity Gateway containing the id_token.

Back to top

Using Mobile Connect Authorization

The SDK allows you to call the Identity Gateway with the scope parameter set to “mc_authz”, which signifies an authorization request for a single transaction (the id_token and access token returned from the Gateway have a timeout set to zero, so expire after a single use). You should check that the Identity Gateway supports version 1.2 of the Mobile Connect Profile (available in the Provider Metadata) before attempting a call, but note that the SDK sets the version to “mc_v1.2” automatically.

To make a successful authorization call, you must provide the following additional parameters:

  • client_name – specifies the name of the application/service requesting authorization. This must match the Application Short Name returned by the Discovery service. If no client_name is specified, the SDK will handle this for you.
  • context – specifies the reason for the authorization request, and should be built from the data describing the transaction requiring authorization. The context is displayed on the authenticating (mobile) device only.
  • binding_message – specifies a reference string to display on the device from which the authorization request was invoked, and on the authenticating (mobile) device, allowing the user to visually verify that the confirmation message originated from their transaction request.

Note: the authorization prompt displayed to the user combines all three parameters, which cannot exceed 93 bytes in total.

The following example shows how to add the additional options to the authentication call described in Using Mobile Connect Authentication, resulting in a correctly configured call to the authorization service.

var authOptions = new MobileConnectRequestOptions
{
    Scope = MobileConnectConstants.MOBILECONNECTAUTHORIZATION,
    Context = "trans 123", //context of the transaction
    BindingMessage = "jamaica clock", //unique user recognisable message
};

MobileConnectStatus newResponse = _mobileConnect.StartAuthentication(discoveryResponse, subscriberId, state, nonce, authOptions); //same as Authentication example

The level of authentication required to authorise the transaction defaults to LoA2 (Authorization), but you can increase it by adding the optional parameter acr_value and setting the value to "3" (for Authorization Plus).

Back to top

Using Mobile Connect Identity and Attributes

A successful call to the Authorization endpoint returns an id_token identifying the user, and an access token that grants your application permission to request their personal information (referred to as Claims). This information contains a range of data; the exact data you can request is specified in the access token, and is limited to those Claims the end user has permitted as part of the original authorization request.

Note: the access token is for single use only, and expires immediately upon use.

You request access to the Identity endpoint by specifying the appropriate scope. The SDK provides constants that you can pass when requesting specific Identity products:

  • Identity: Phone Number – MOBILECONNECTIDENTITYPHONE
  • Identity: Sign-up – MOBILECONNECTIDENTITYSIGNUP
  • Identity: National Identity – MOBILECONNECTIDENTITYNATIONALID

Upon successful authorization, the SDK provides an IdentityResponse with the user information JSON available as a property. The following example can be used to convert the JSON data to a class - IdentityData - which is provided with all recognised claims.

MobileConnectStatus response = await _mobileConnect.RequestIdentityAsync(discoveryResponse, accessToken, new MobileConnectRequestOptions());
// IdentityData is a JSON serializable class containing properties for all available Identity claims
// It can be replaced by any JSON serializable type, either to add additional supported claims
// or to provide a lightweight class with only the required claims
IdentityData identity = response.IdentityResponse.ResponseDataAs<IdentityData>();

The following example shows how to add the additional Authorization and Identity options to the Authentication call described in Using Mobile Connect Authentication, resulting in a correctly configured call to the Identity: Phone Number service.

Note: calls to Identity: Sign-up and Identity: National ID are structured in exactly the same way, but using the constant MOBILECONNECTIDENTITYSIGNUP or MOBILECONNECTIDENTITYNATIONALID as applicable.

var authOptions = new MobileConnectRequestOptions
{
    Scope = MobileConnectConstants.MOBILECONNECTIDENTITYPHONE,
    Context = "trans 123", //context of the transaction
    BindingMessage = "jamaica clock", //unique user recognisable message
};

MobileConnectStatus newResponse = _mobileConnect.StartAuthentication(discoveryResponse, subscriberId, state, nonce, authOptions); //same as Authentication example

Back to top

Using Mobile Connect Server-to-Server (Headless) Operation

MNOs have the option to enable headless operation in their Identity Gateway. This server-to-server configuration allows your server-side applications/services to make calls to the Mobile Connect endpoints without any user interaction via a client application or browser. Headless operation supports implementations where the user’s MSISDN is provided by a third-party system – a call centre Interactive Voice Response (IVR) system, for example.

The Mobile Connect SDK handles the configuration needed for headless operation. Following a successful Discovery response containing the URL to the MNO’s Identity Gateway, the SDK handles the call to the requested endpoint (Authentication, Authorization, or Identity) in the following ways:

  • The prompt parameter is set to “mobile”, ensuring that all user interactions are sent via the user’s mobile device.
  • The SDK waits for a response from the endpoint (in the form of a redirect to your registered redirect URL) following either a successful user authentication or an error. If the wait time exceeds the timeout interval (defaulting to two minutes, but you can set a different duration) then a timeout error is generated and returned to your application.
  • The SDK can cancel an in-progress request when instructed by your application/service.

The following function enables headless operation in your server application.

[HttpGet]
        [Route("headless_authentication")]
        public async Task<IHttpActionResult> RequestHeadlessAuthentication(string sdksession = null, string subscriberId = null, string scope = null)
        {
            var options = new MobileConnectRequestOptions
            {
                Scope = scope,
                Context = "headless",
                BindingMessage = "demo headless",
                AutoRetrieveIdentityHeadless = true,
            };

            var response = await _mobileConnect.RequestHeadlessAuthenticationAsync(Request, sdksession, subscriberId, null, null, options);
            return CreateResponse(response);
        }

Further Reference

Back to top