OAuth2 plugin
|
This plugin implements OAuth2 (RFC6749) support in Qorus Integration Engine.
Before client can be usetd to obtain access token. It has be registered in Qorus system. For client administration there is dedicated REST API described in OAuth2 REST API v1
This plugin supports 4 types of Authorization flows as described in Obtaining Authorization of the RFC. To obtain access code for further communication with resource server REST API /oauth2/v1/public/token must be used. When calling this REST API method correct parametres must be specified depending on the grant type.
This flow consists of several steps:
Get Authorization Code
Request to /oauth2/v1/public/token must provide parameters:
response_type
: value MUST be set to "code"client_id
: client identifierredirect_uri
scope
: (optional)state
: (optional)The REST api redirects the request internally to the approval login page where the user will approve access to his resources for the client. After the user approves this, another REST API is called internally (/oauth2/v1/code) which generates the authorization code and returns it to the client.
Get Access Token
The client has to exchange the autorization code for access token by calling /oauth2/v1/public/token again, this time with parameters:
grant_type
: value MUST be set to "authorization_code"code
: the authorization code received from the authorization serverredirect_uri
: if the "redirect_uri" parameter was included in the authorization request as described in Section 4.1.1, and their values MUST be identical.client_id
: if the client is not authenticating with the authorization server as described in Section 3.2.1.Request for access token needs to be sent as HTTP POST.
The response consists of:
access_token
: access token to be used to access protected resourcetoken_type
: authentication type to be used in request header, "bearer" hardcodedexpires_in
: milisecond after which the token expires if not usedSimilar to previus grant rest_api_oauth2_v1_public_token, but this time the authorization code is not involved, the access token is isssued directly instead. The REST api redirects the request internally to the approval login page where the user will approve access to his/her resources for the client. After the user approves this, another REST API is called internally (/oauth2/v1/code) which generates the access token and returns it to the client.
Request to /oauth2/v1/public/token must provide parameters:
response_type
: value MUST be set to "token"client_id
:redirect_uri
scope
: (optional)state
: (recommended)Request for access token needs to be sent as HTTP POST.
The response consists of:
access_token
: access token to be used to access protected resourcetoken_type
: authentication type to be used in request header, "bearer" hardcodedexpires_in
: milisecond after which the token expires if not usedRequest to /oauth2/v1/public/token must provide parameters:
grant_type
: value MUST be set to "password"username
: name of the userpassword
: user's passwordscope
: (optional)Request for access token needs to be sent as HTTP POST.
The response consists of:
access_token
: access token to be used to access protected resourcetoken_type
: authentication type to be used in request header, "bearer" hardcodedexpires_in
: milisecond after which the token expires if not usedRequest to /oauth2/v1/public/token must provide parameters:
grant_type
: value MUST be set to "client_credentials"scope
: (optional)Request for access token needs to be sent as HTTP POST.
The response consists of:
access_token
: access token to be used to access protected resourcetoken_type
: authentication type to be used in request header, "bearer" hardcodedexpires_in
: milisecond after which the token expires if not used