Fellowship One REST API

Single Sign On Host Implementation

This extension\’s intent is to give an authorized site (Site A) with a signed in user the ability to direct that user to another authorized site (Site B) without forcing the user to log in again. This portion is strictly for the host implementation of single sign on.

OAuth Core 1.0 references and definitions can be viewed : OAuth
Fellowship One OAuth Extension document can be viewed here
Fellowship One OAuth Extension repository can be accessed here

Overview

• Prerequisite - Site B will need to have their landing page added to their application data in the Fellowship One database.
• Step 1 - Site B will be determined by the passed applicationID and the user will be redirected to Site B's single sign on landing page with a ssoAuthURL, requestToken and redirectURL for Site B.
• Step 2 - Site B will then request an accessToken from the ssoAuthURL using a standard OAuth request with their consumerKey, consumerSecret and requestToken.
• Step 3 - Site B will receive an accessToken and an id of the individual that was logged into Site A's site.
• Step 4 - Site B then should do whatever steps necessary to consider a user "logged in" for their site and then redirect them to the redirectURL.

Details

Site B will need to implement a landing page for Fellowship One Single Sign On. This landing page will be associated with Site B's applicationID and will be the page that handles the following steps for Site B.

• Step 1 - After Site A redirects the user in step 2, the Fellowship One Single Sign On will then pass the user to Site B's landing page wtih a ssoAuthURL, requestToken and redirectURL.
  • Ex. landing page: https://portal.fellowshipone.com/bridge/login/SingleSignOn/Index?ssoAuthURL=https://churchcode.fellowshiponeapi.com/v1/SSO/Token&requestToken=afd011d3-fbd3-4c69-8326-a24fad8d0c34&redirectURL=https://portal.fellowshipone.com/Payment/RDCBatch/Pending.aspx?batch_id=1
  • Generic ex: AppSite/LandingPage?ssoAuthURL=https://churchcode.fellowshiponeapi.com/v1/SSO/Token&requestToken=afd011d3-fbd3-4c69-8326-a24fad8d0c34&redirectURL=https://portal.fellowshipone.com/Payment/RDCBatch/Pending.aspx?batch_id=1
    • ssoAuthURL - The URL that Site B will need to make a signed request to in order to get an accessToken.
    • requestToken - The requestToken, generated by the Single Sign On process, that Site B will need to exchange for an accessToken. It can only be used one time and lives for only 60 seconds after creation by the Single Sign On process.
    • redirectURL - The exact page that Site A desired to send the user to.
• Step 2 - Site B will need to make a signed request to the Fellowship One Single Sign On Token action (ssoAuthURL) in order to get an accessToken in return.
  • This request is signed using OAuth signing requests
    • Site B will sign the request using the requestToken and without a token secret.
  • Ex. ssoAuthURL: [GET] https://churchcode.fellowshiponeapi.com/v1/SSO/Token
• Step 3 - The Fellowship One Single Sign On Token action will provide Site B with an accessToken and individualID via:
  • Response body: ex. oauth_token=afd011d3-fbd3-4c69-8326-a24fad8d0c34&oauth_token_secret=ab86c226-fc65-4d32-a33c-8b54a753655e&id=1
  • Header:
    • oauth_token=afd011d3-fbd3-4c69-8326-a24fad8d0c34
    • oauth_token_secret=ab86c226-fc65-4d32-a33c-8b54a753655e
    • id=1
• Step 4 - Site B now has an accessToken and individualID and can follow their normal steps to fetch and store whatever information they need about an individual that is necessary for their site. They should then redirect the user to the originally intended destination (redirectURL) as best practice.
  • Ex: In portal after getting back the individualID we fetch access right information for that individual, which is necessary information for all users of portal. We then redirect to the redirectURL.