The goal of this page is to show an example flow of Privakey CX, to facilitate understanding of the system. The flow used on this page is:
- Retrieve an existing user's identifier
- Enable Privakey for that user
- Challenge that user
- Receive that user's response to the Challenge
Note there are two methods to achieve steps one and two. The first is via the Simple Bind method, which allows Privakey CX is the system of authority on the user, and it receive bind requests from a Request Origin. The second is via an Identity Provider, in which the user allows Privakey CX.to authenticate the user on their behalf, and in which the Identity Provider is the system of authority.
The entire flow, including Simple Bind, is shown graphically here, with each step detailed further down.
Using the second method, IDP Bind, is detailed at the end of this page.
In order to enable Privakey for a user, you'll need that user's unique identifier. In your system, each user likely already has a unique identifier. This could be an int, a GUID, an email, etc. This identifier will be passed from the user's app to your Request Origin, and finally to the Privakey CX Auth Service.
The typical way to get a user's identifier is to have them log in to the service from their app. When they do so, you'll return some info back to the Mobile App. Part of this info should be their unique identifier.
Using the identifier retrieved in Step 1, the next step is to Enable Privakey for that user. This process is called Binding, because it binds one of your accounts to a Privakey account.
The Binding process must be started from one of your Request Origins. This is for security reasons, which are detailed further in the documentation. However, the Request Origin doesn't already know which user to Bind. Thus, the Mobile App tells the Request Origin which user it wants to Bind. The Request Origin forwards this info to Privakey CX, which performs the Bind operation. If successful, Privakey CX responds with some data that the Request Origin must send to the Mobile App. The Mobile App then finishes the binding process in the background (not shown in Figure 3).
The user is now set up to use Privakey CX!
When the user wants to do something high stakes, like check their bank account, you can now Challenge them. This will send the user a notification and let them act upon the Challenge. You should put their attempted action on hold until you get the result of the Challenge. Which brings us to...
When the user acts upon the Challenge, Privakey CX will (optionally) let your Request Origin know. At this point, you can proceed with the attempted action (E.G. show them their bank account).
Privakey CX requires a unique user identifier, and to this end, it can obtain it from a supported Identity Provider. In order to do so, a Mobile App associated to an App Space that is configured to leverage an IDP may initiate the bind request. In doing so, the user will be redirected by the Auth Service on their device to the IDP's authentication page. There they can complete a login, allowing the app to use the first half of the authentication process in the next step.
With the authorization credential served by the Identity Provider, the Mobile App will forward that information to Privakey CX, allowing it to complete the authentication process on behalf of the user. After brokering with the IDP, the user's identifier will be returned and stored on Privakey CX, which then instructs the Mobile App to complete the bind process. The Mobile App then finishes the binding process in the background (not shown in Figure 8).
After this, steps 3 and 4 proceed as normal.
That concludes the general flow using Privakey CX.
Updated almost 3 years ago