Joe Designer works at Awesome Architects, LLC. a Jive customer. Joe is currently kicking off a construction project that is made up of people from a number of different companies. Because the team is geographically distributed and has enterprise boundaries, they have agreed to use the SaaS solution from MyPlanner.com for project management, which conveniently offers a Jive App! Now, Joe does not have a pre-existing relationship or account with MyPlanner.com. He simply installs the MyPlanner app, and expects the system to recognize him, or at least walk him through the new user provisioning process.
There are two possible mechanisms for Joe's information to be made available to MyPlanner.com.
2-Legged OAuth (aka "Signed Fetch")
The below diagram illustrates the 2-Legged oAuth or signed fetch approach. In this scenario the Jive Apps developer MyPlanner.com does not need to be an oAuth provider.
MyPlanner.com would create and expose custom endpoints on their infrastructure to respond to signed-fetch requests originating from one or more Jive instances. These endpoints would be responsible for unpacking the signed fetch requests, and establishing a new record for the user. This approach has the advantage of relying on the Jive instance to authenticate the user, and thus doesn't require the end user to specify a different set of credentials to authenticate against MyPlanner.com. However, if MyPlanner.com wishes to allow access to its services outside of the Jive app, it will have to implement a mechanism to allow the Jive user to authenticate against its servers outside of the trusted signed fetch that occurs within the app context. This might involve prompting the user for a username and password for use outside of the app context.
- Jive App makes a signed fetch request to its home server
- The signed fetch is proxied by the Jive Open Social container which signs the request with the consumer key/secret and forwards it to the Jive Apps Gateway
- The gateway verifies the signature of the request as being from a legitimate Jive instance with permissions to make such a request. It then re-signs the request with the consumer key/secret associated with the Jive App making the request and sends the request along to the home server
- The home server receives the request and verifies its integrity by verifying the oauth signature in the request that gateway created using consumer key and secret that was provided to the application developer at the time of registration.
- It can then pull out the opensocial_owner_id param from the request and split this into its component values of jive_user_id (a numeric id unique to the particular jive instance) and the jive_instance_id (a globally unique identifier for the jive instance).
- It is now up to the home server to process the jive user id and jive instance id in a way that is meaningful, presumably by creating a new user record with which it can associate future requests for which it can store other information.
- If more information is required by the home server for a given jive user id, the app can request it from either the jive instance or the end user himself. With that information in hand, the app can then pass it along to the home server
The other mechanism would be to use traditional 3-legged OAuth as described in this doc, Using OAuth in your applications. This would require that the home server implement the OAuth provider interfaces, and provide the registration and login flows. This approach has the advantage that any user registered with the home server in this way can access the system from any client, and not just the Jive app. The downside is that it requires yet another set of credentials that the user must remember.