An authentication provider must provide a complete, self contained mobile website (msite) for authentication. This is a user facing site, which will be presented to the user whenever authorisation is needed. The msite can use whatever branding or design deemed appropriate.
The msite is a straightforward mobile website, presented in-app within a modal dialog that is 700×656 pixels in size (on iPhone iOS6 the viewport is 240x208px and on iPhone iOS7 it is 280x248px). It is the same size in both landscape & portrait orientation:
￼You should test your Msite within an app to ensure it displays correctly and is not obscured when the keyboard is displayed, especially in landscape orientation. If your app supports iPhone then it is recommended that you test the msite on both 3.5 inch screen and 4 inch screen as well as different iOS versions.
Your Msite must provide authentication but may also provide other services to the user, such as user registration and so on. The Msite can present any applicable content to the user, but upon successful authentication it must let the host Oomph application know that authentication has succeeded. It does not need to notify the host app if authentication fails.
The Msite should not maintain any state in session variables, cookies and so on. It is very important that your msite behaviour is consistent each time it is accessed, even when it is accessed by the same user.
A unique identifier for the device is passed in the call to the msite in a "udid" query string parameter. It is up to you to use this how you see fit, or not at all. You could for example track or limit the amount of concurrent registrations to your authenticator to some finite number of devices. However, we do not recommend this as it is generally a bad user experience. If you choose to do this you should also provide a way for a user to remove devices from their approved devices list, which is important if the user upgrades or loses their iPad, for example.
Note that the unique device identifier may not represent a single device across application installs. You should think of the unique ID more as an installation identifier rather than a device identifier. The unique ID is not an Apple "UDID", as Apple no longer allows the UDID to be used in App Store applications.
Note: The Msite must not provide a purchase mechanism that allows purchasing of content outside of Apple’s in-app purchasing mechanism. This is a violation of Apple’s developer agreement and will cause an app to be rejected.