While these are the preferred methods, a third method that does not use intents allows the customer to keep their existing launcher for user sign-on process and then pass the user information to the Profile Client to authentication with the Profile Manager.
This method uses the following four tags (described in JSON Configuration Variable for WFC Profile Client table ):
The values entered in these tags identify the input fields to automate the login process.
Following is sample HTML of a sample login screen:
<div class="input-row"
<table>
<tr>
<td>
<p> <label style="margin-top:-14px" for="username">Login ID:</label></p>
</td>
<td>
<span class="ctrl">
<input type="text" name="username" id="username" class="textinput" value=""/>
</span>
</td>
</tr>
</table>
</div>
<div class="input-row">
<table>
<tr>
<td>
<p> <label style="margin-top:-14px" for="password">Password:</label></p>
</td>
<td>
<span class="ctrl">
<input type="password" name="password" id="password" class="textinput" autocomplete="off"/>
</span>
</td>
</tr>
</table>
</div>
<div class="button-row">
<span class="ctrl">
<input type="submit" value="Login" id="submit" class="formButton" onclick="this.disabled=true;document.body.style.cursor = 'wait'; this.className='formButton-disabled';form.submit();return false;"/>
The highlighted fields in the HTML example are the content of the login screen sent to the mobile device from the customer’s authentication system. Once authenticated, the Profile Client receives the credentials through an intent from the third-party launcher application and passes the credentials to the appropriate tagged fields. The Profile Client receives the input from the launcher through intent, and then provides the input to the User ID = id="username", and Password = id="password" entries. These fields are sent back to the authorizing system with id=”submit”.
By correctly identifying the HTML entry ID Fields, the third-party application can pass the credentials to the Profile Client to log in with these credentials.
Key_user_name
: “
username
”
The domain prefix is not shown in this example.
Third-party launchers can send an access token (
user_accesscode
), refresh token (
refresh_token
) and the refresh token expiration time (
refresh_token_expiration
) in seconds. Access tokens take precedence over the user name and password fields.
When the
refresh_token_expiration
time elapses, the user is signed out. Third-party launchers must send a new intent with the refreshed
user_accesscode
,
refresh_token
, and
refresh_token_expiration
before the expiration time of the previous toke elapses.
