Authentication Model

If you are creating a mobile app or website that requires access to secure customer information (for example, login details, account functionality) you will need to use one of following two options to access these details:

  • Native Scenario (Client Device Application) -  (for example: mobile) using the Sessions API must only be employed for direct connections between client and server. For example, the SSL connection is unbroken between the device where the customer enters credentials and The William Hill API (TWHAPI) server. An example of this is a native iPhone application using the TWHAPI services directly.
  • Web Scenario - login via a partner website. The customer presents their William Hill credentials to a William Hill authentication service, then after a successful login the customer is redirected back to the partner service and that service can then make use of the William Hill APIs. In this case there is a secure (SSL) connection from the user's device to the partner service and another from that service to the TWHAPI server.

Client Device Application - Sessions API

Website - CAS (Central Authentication Service)

Configuring CAS for Third Parties

Authentication flows

The diagram below illustrates the possible options for customer authentication:

Mobile Device Authentication Flows

  • The flow in black shows client device application customer login directly with the Sessions API and then using other William Hill APIs.The following table explains the flow in detail:
     
    Arrow Description
    1. Username/Password The mobile device the customer is using, sends credentials to the Sessions API.
    2. Authentication Ticket The request to Sessions API returns an Authentication Ticket to the mobile device, valid for a set period of time.
    3. Accounts, Bets...requests+Authentication Ticket With the ticket that has been just acquired, the customer can place bets, query the account and perform other requests to other William Hill APIs.
  • The flow in red shows client device application customer login directly with the Sessions API and then using other non-API William Hill services. The following table explains the flow in detail:
     
    Arrow Description
    1. Authentication Ticket The customer sends an Authentication Ticket from the mobile device to the Sessions API. 
    2. Service Ticket The request to Sessions API returns a Service Ticket.
    3. Other Service+Service Ticket The Service Ticket allows the customer to access other CAS-enabled William Hill Services. 

     

Customer using a Desktop Browser Authentication Flow 

The flow in blue shows customer login from a website that can the make requests to William Hill APIs or other services on behalf of that user. The following table explains the flow in detail:

Arrow Description
1. Username/Password The desktop device the customer is using, sends credentials to the Central Authentication Server (CAS).
2a. Redirect The Central Authentication Server (CAS)  redirects the customer by sending a redirect URL to the customer's browser.
2b. Redirect The customer is redirected to a third-party website. 
3. Proxy Authentication Ticket The Central Authentication Server (CAS) sends a  Proxy Authentication Ticket to the third-party website. 
4. Accounts, Bets...requests The customer requests to be logged in and place bets, query the account, top up the acoounts and so on to the third-party website.
5a. Accounts, Bets...requests+Proxy Authentication Ticket Using the Proxy Authentication Ticket the customer is logged in on the third-party website and can place bets, query the account, top up the acoounts and so on.
5b. Other Services The customer can use other William Hill CAS-enabled services.