You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Toopher's `iframe`-based authentication flow is the simplest way for web developers to integrate Toopher Two-Factor Authentication into an application.
3
+
Toopher's `<iframe>`-based authentication flow is the simplest way for web developers to integrate Toopher Two-Factor Authentication into an application.
4
4
5
-
## Toopher `iframe` Authentication Overview
5
+
## Toopher `<iframe>` Authentication Overview
6
6
7
7
The `iframe`-based authentication flow works by inserting an `<iframe>` element into the HTML displayed to the user after a successful username/password validation (but before they are actually logged-in to the service). The `iframe` URL is generated by our library and its content is served from the Toopher API server. The `iframe` guides the user through the process of authenticating with Toopher. Once complete, the `iframe` will return the result of the authentication to your server by `POST`ing the response via HTML to an endpoint of your choice. Your server validates the cryptographic signature using our library which determines whether or not the user successfully authenticated.
8
8
9
9
Two distinct `iframe` flows are available:
10
10
11
-
***Simple** serve an all-in-one `iframe` that handles *Pairing* and
12
-
*Authentication*
11
+
***Simple** serve an all-in-one `iframe` that handles *Pairing* and *Authentication*
13
12
***More flexible** serve the *Pairing*`iframe` and the *Authentication*`iframe` as needed. Note: a *Pairing* request is used to pair a user account with a particular mobile device (this is typically a one-time process); an *Authentication* request is used to authenticate a particular action on behalf of a user
14
13
15
14
## Authentication Workflow
16
15
17
-
### Step 0: Primary Authentication
18
-
16
+
### Primary Authentication
19
17
We recommend using some form of primary authentication before initiating a Toopher authentication request. Typical primary authentication methods involve verifying that the user has a valid username and password to access the resource being protected.
20
18
21
19
### Step 1: Embed a request in an `<iframe>`
22
-
23
20
After verifying the user's primary authentication, but before Assuming the user's primary authentication checks out, the next step is to kickoff Toopher authentication.
24
21
25
22
1. Generate a URI by specifying the request parameters to the library as detailed below
26
23
1. Display a webpage to your user that embeds this URI within an `<iframe>` element. The markup requirements for the `<iframe>` element are described in the "HTML Markup" section
27
24
28
25
### Step 2: Validate the result
29
26
1. Toopher-iframe results posted back to server
30
-
1. Server calls `ToopherIframe.validate()` to verify that result is valid. `.validate()` returns a `Map` of trusted data if the signature is valid, or throws a `SignatureValidationError` if the signature is invalid.
27
+
1. Server calls `ToopherIframe.validatePostback()` to verify that result is valid. `.validatePostback()` returns a `Map` of trusted data if the signature is valid, or throws a `SignatureValidationError` if the signature is invalid.
31
28
1. The server should check for possible errors returned by the API in the `error_code` map entry
32
29
1. If no errors were returned, the result of the authentication is in the `granted` map entry
33
30
@@ -47,9 +44,9 @@ There is no difference in the markup required for a Pairing vs. an Authenticatio
47
44
48
45
### All-in-one iframe
49
46
50
-
#### Generating an iframe URI
47
+
#### Generating an iframe URL
51
48
52
-
Every Toopher Authentication session should include a unique `requestToken` - a randomized `String` that is included in the signed request to the Toopher API and returned in the signed response from the Toopher `iframe`. To guard against potential replay attacks, your code should validate that the returned `requestToken` is the same one used to create the request.
49
+
Every Toopher Authentication session should include a unique `requestToken` - a randomized `String` that is included in the signed request to the Toopher API and returned in the signed response from the Toopher `<iframe>`. To guard against potential replay attacks, your code should validate that the returned `requestToken` is the same one used to create the request.
53
50
54
51
Creating a random request token and storing it in the server-side session using the Java Servlet API:
55
52
@@ -60,11 +57,11 @@ Creating a random request token and storing it in the server-side session using
60
57
61
58
The Toopher Authentication API provides the requester a rich set of controls over authentication parameters.
// There was an error -- user should not be authenticated
@@ -104,78 +101,8 @@ In this example, `data` is a `Map<String, String[]>` of the form data POSTed to
104
101
// went wrong (incorrect session token, expired TTL, invalid signature)
105
102
}
106
103
107
-
### Separate Pairing and Authentication iframes
108
-
109
-
#### Generating an Authentication iframe URI
110
-
111
-
Every Toopher Authentication session should include a unique `requestToken` - a randomized `String` that is included in the signed request to the Toopher API and returned in the signed response from the Toopher `iframe`. To guard against potential replay attacks, your code should validate that the returned `requestToken` is the same one used to create the request.
112
-
113
-
Creating a random request token and storing it in the server-side session using the Java Servlet API:
114
-
115
-
private static final SecureRandom secureRandom = new SecureRandom();
116
-
// simple way to generate a randomized string.
117
-
String requestToken = new BigInteger(20 * 8, secureRandom).toString(32);
#### Validating postback data from Authentication iframe and parsing API errors
106
+
#### Generating a Pairing iframe URL
133
107
134
-
In this example, `data` is a `Map<String, String[]>` of the form data POSTed to your server from the Toopher Authentication `iframe`. You should replace the commented blocks with code appropriate for the condition described in the comment.
135
-
136
-
Map<String, String[]> data = httpServletRequest.getParameterMap();
Copy file name to clipboardExpand all lines: README.md
+26-5Lines changed: 26 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ Make sure you visit (http://dev.toopher.com) to get acquainted with the Toopher
16
16
The first step to accessing the Toopher API is to sign up for an account at the development portal (http://dev.toopher.com) and create a "requester". When that process is complete, your requester is issued OAuth 1.0a credentials in the form of a consumer key and secret. Your key is used to identify your requester when Toopher interacts with your customers, and the secret is used to sign each request so that we know it is generated by you. This library properly formats each request with your credentials automatically.
17
17
18
18
#### The Toopher Two-Step
19
-
Interacting with the Toopher web service involves two steps: pairing, and authenticating.
19
+
Interacting with the Toopher web service involves two steps: pairing and authenticating.
20
20
21
21
##### Pair
22
22
Before you can enhance your website's actions with Toopher, your customers will need to pair their phone's Toopher app with your website. To do this, they generate a unique, nonsensical "pairing phrase" from within the app on their phone. You will need to prompt them for a pairing phrase as part of the Toopher enrollment process. Once you have a pairing phrase, just send it to the Toopher API along with your requester credentials and we'll return a pairing ID that you can use whenever you want to authenticate an action for that user.
@@ -34,13 +34,25 @@ import com.toopher.*;
34
34
ToopherAPI api =newToopherAPI("<your consumer key>", "<your consumer secret>");
// With username, terminal name and requester specified Id (Returns exception if terminal is not found)
50
+
AuthenticationRequest auth = api.authenticate("username", "my computer", "requesterSpecifiedId")
51
+
// With username and terminal name (New terminal is created if terminal is not found)
52
+
AuthenticationRequest auth = api.authenticate("username", "my computer")
41
53
42
54
// Once they've responded you can then check the status
43
-
AuthenticationStatus status = api.getAuthenticationStatus(auth.id);
55
+
auth.refreshFromServer()
44
56
if (status.pending ==false&& status.granted ==true) {
45
57
// Success!
46
58
}
@@ -62,8 +74,17 @@ Alternatively, you can consume this library using Maven:
62
74
</dependency>
63
75
64
76
#### Try it out
65
-
Check out `com.toopher.ToopherAPIDemo.java` for an example program that walks you through the whole process! A runnable jar for the demo can be built and executed as follows:
77
+
Check out `com.toopher.ToopherAPIDemo.java` for an example program that walks you through the whole process!
78
+
79
+
###Ant
80
+
A runnable jar for the demo can be built and executed in Ant as follows:
0 commit comments