{"_id":"5a0b0d9b04d0d600269f1388","category":{"_id":"5a0b0d9b04d0d600269f1376","version":"5a0b0d9b04d0d600269f1373","project":"573c7e3b9eef3a0e00b51c58","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-09-13T19:58:29.432Z","from_sync":false,"order":2,"slug":"itegration-guide","title":"Integration Guide"},"project":"573c7e3b9eef3a0e00b51c58","user":"573c7e0afe58321900f1b97d","version":{"_id":"5a0b0d9b04d0d600269f1373","project":"573c7e3b9eef3a0e00b51c58","__v":1,"createdAt":"2017-11-14T15:36:59.500Z","releaseDate":"2017-11-14T15:36:59.500Z","categories":["5a0b0d9b04d0d600269f1374","5a0b0d9b04d0d600269f1375","5a0b0d9b04d0d600269f1376","5a0b0d9b04d0d600269f1377","5a0b0d9b04d0d600269f1378"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2.0"},"__v":0,"parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-09-13T21:12:21.627Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":4,"body":"Once the core, OpenID Connect Protocol has been enabled within the Relying Party, interfaces and controls must be implemented to leverage the service.   \n\nAs noted previously, this discussion focusses using Privakey as a User-Opt-In option and, for clarity sake, covers the most basic user registration models: user, self-service registration.  \n\nFor a User-Opt-In model there are two key contexts a Relying Party will need to add interfaces and controls:\n\n1.\tThe Relying Party service must allow new or existing user to register or login using Privakey as their authentication method.\n2.\tThe Relying Party service must implement a way to allow existing users to change between Privakey and User-Name and password.\n\nDepending on the sophistication of the account recovery model employed at the Relying Party, one may also need to:\n\n3.\tAugment account recovery to support Privakey authentication \n\nRepresentative design constructs and best practices are presented in the following sections.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"1.\\tLogin / Register with Privakey\"\n}\n[/block]\nLogging in and Registering with Privakey follow very similar processes, as outlined above in [Privakey Authentication, step 6: Authenticate the user.](http://docs.privakey.com/v1.0/docs/privakey-authentication#6-authenticate-the-user). In fact, the same conditional control can be leveraged, authenticating a user if they are found (i.e. the sub returned by the ID Token is found) in the User Model and initiating new user registration if the user is not found.  Illustrative designs for each of these contexts is included below: \n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/563dc32-Picture1.png\",\n        \"Picture1.png\",\n        405,\n        339,\n        \"#e6e7e7\"\n      ],\n      \"caption\": \"Registration\"\n    }\n  ]\n}\n[/block]\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/1209eb6-Picture2.png\",\n        \"Picture2.png\",\n        269,\n        334,\n        \"#e9eaeb\"\n      ],\n      \"caption\": \"Login\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"develop-interfaces-and-controls","type":"basic","title":"Develop Interfaces and Controls"}

Develop Interfaces and Controls


Once the core, OpenID Connect Protocol has been enabled within the Relying Party, interfaces and controls must be implemented to leverage the service. As noted previously, this discussion focusses using Privakey as a User-Opt-In option and, for clarity sake, covers the most basic user registration models: user, self-service registration. For a User-Opt-In model there are two key contexts a Relying Party will need to add interfaces and controls: 1. The Relying Party service must allow new or existing user to register or login using Privakey as their authentication method. 2. The Relying Party service must implement a way to allow existing users to change between Privakey and User-Name and password. Depending on the sophistication of the account recovery model employed at the Relying Party, one may also need to: 3. Augment account recovery to support Privakey authentication Representative design constructs and best practices are presented in the following sections. [block:api-header] { "type": "basic", "title": "1.\tLogin / Register with Privakey" } [/block] Logging in and Registering with Privakey follow very similar processes, as outlined above in [Privakey Authentication, step 6: Authenticate the user.](http://docs.privakey.com/v1.0/docs/privakey-authentication#6-authenticate-the-user). In fact, the same conditional control can be leveraged, authenticating a user if they are found (i.e. the sub returned by the ID Token is found) in the User Model and initiating new user registration if the user is not found. Illustrative designs for each of these contexts is included below: [block:image] { "images": [ { "image": [ "https://files.readme.io/563dc32-Picture1.png", "Picture1.png", 405, 339, "#e6e7e7" ], "caption": "Registration" } ] } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/1209eb6-Picture2.png", "Picture2.png", 269, 334, "#e9eaeb" ], "caption": "Login" } ] } [/block]