Overview
This article describes one method of getting authentication tokens from Jive through the OAuth 2.0 Code Grant. In the next section, the workflow, and the requirements to grant the authorization will be outlined.
Information
Environment: All Jive Cloud and Jive Hosted/On-Premise versions.
Implementation: OAuth 2.0 specification.
It is required to have an OAuth 2.0 Client add on, either it is installed from the registry or uploaded to the Jive instance.
The general flow for the OAuth 2.0 authorization code grant is as follows:
The user logs in to the client's web application in a browser.
- Client directs the user to the Jive's authorization end-point (typically in a new iframe), which is
<jive-url>/oauth2/authorize
. - Client includes the required parameters
client_id=<client_id>&response_type=code,
and any optional parameters (scope, state or redirect_url
). - If the browser doesn't have a logged in session for Jive, Jive will ask the user to log in first.
- Jive presents an authorization screen asking the user to allow or deny the authorization grant (scope is not shown to the user at this time).
- Assuming the customer allows authorization, Jive will redirect to user back to the redirect_url (if it was sent to the authorization end-point) or to the redirect_url provided in the add-on.
-
A short lived authorization code is attached as a query parameter to the redirect URL along with state parameter if it was provided earlier:
https://client.application.com/oauth2/redirect?code=<AUTHZ_CODE>
- Client makes a POST request to the token end-point authorizing the request using client credentials:
curl -u '<CLIENT_ID>:<CLIENT_SECRET>' -d 'code=<AUTHZ_CODE>&grant_type=authorization_code&client_id=<CLIENT_ID>' https://<JIVE-URL>/oauth2/token
- Jive responds with something like:
{ "qwergqefq5bad5fp03rwjwzzyh3da8vyha92wm6f.t", "refresh_token""79wr2gsl32m8xgwxcxbc027fsjzn5sf0l7wrn3g3.r",
"token_type":"bearer",
"expires_in":"172799"
}
Comments
0 comments
Please sign in to leave a comment.