Autorizācijas koda saņemšana
Description
This operation entails performing an authorization code grant type OAuth 2.0 request request. In contrast to the other Integration platform APIs (except SignAPI), the messages of this operation are not exchanged directly between the Service provider's application and Integration platform but rather indirectly via the end-user's browser using browser redirects.
This operation lets an Service provider's application obtain authorization from the end-user for accessing one of their resources or their identity data. The end-user's authorization is obtained via an authorization code credential. The authorization code is sent via the browser as a response from the operation. The Service provider's application exchanges the authorization code for the corresponding access token for accessing the resource.
Request
To start the authorization code grant flow, the Service provider's application directs the end-user's browser to one of Authorization server /trustedx-authserver/oauth/ endpoints. As a result of this redirect, the browser sends an HTTP request like the following, which corresponds to the OAuth 2.0 authorization request message. The request must be sent by TLS and use the GET method.
GET /trustedx-authserver/oauth/{as}?response_type=code& client_id=...& state=...& redirect_uri=...& scope=...& prompt=...& acr_values=...& ui_locales=...& sign_identity_id = ...& digests_summary = ...& digests_summary_algorithm = ...&
Note |
---|
All the applications integrated with Integration platform authorization server via browser redirect (OAuth 2.0) must do so using a consistent base URL that has the same DNS domain name, the same port (by default, 8082) and the same Web application name (by default, trustedx-authserver). The browsers must always connect to Integration platform Authorization server using the same base address so the identity provider can maintain the sessions and apply SSO consistently. |
Parameters
Name | Type | Usage | Description |
as | Path | Required | Identifier of the Integration platform authorization server to which the authorization request is sent (Server ID field of one of the Authorization server entities). Available "
|
response_type | Query | Required | Must take the |
client_id | Query | Required | Service provider’s application identifier issued to Service provider by LVRTC |
state | Query | Recommended | We recommend using this parameter to safeguard against CSRF attacks. To do this, the Service provider’s application must include a random value in this parameter, store it in the HTTP session and verify it when the Authorization Response message is received. The random value associates the authorization request with the HTTP session, which safeguards against the Service provider’s application processing an Authorization Response message not returned in response to an Authorization Request message specified previously in the end-user's browser. |
redirect_uri | Query | Required | Redirect URI to the Service provider's application. The Service provider's application waits to receive at this URI the Authorization response/Authentication response message with the authorization code. It must match one of the Redirect URIs registered for the Service provider's application, or a redirect URI of the system. If the Service provider's application was configured to allow any redirect URI (not recommended), this parameter is not checked. This parameter can be omitted if only one specific redirect URI was registered for the Service provider's application. In this case, the registered redirect URI is used. |
scope | Query | Recommended | List of values, separated by spaces, that represent the scope of the authorization that the Service provider’s application wants to obtain. It queries the scopes required for accessing the resources or services in question. Defined scopes:
|
prompt | Query | Recommended | The values login and none are supported:
|
acr_values | Query | Optional | Defines conditions for authenticating the end-user (minimum levels or specific flows) who must authorize the access. Defined authentication methods:
If the parameter is not specified, its displays the available logon methods (end-user can choose). |
ui_locales | Query | Optional | Specifies a list of languages ordered by preference. The end-user interface, available languages and settings:
If the parameter is not specified, a end-user's browser language is used, if that language does not exist, then English language is used instead. |
sign_identity_id | Query | Optional |
Signing Identity received from authenticated end-user data request using |
digests_summary | Query | Optional |
Its value must be the base64 encoded cryptographic hash of the concatenation of the cryptographic hashes of the data to be digitally signed. Value must be encoded as URL safe.
|
digests_summary_algorithm | Query | Optional |
Hash algorithm used to calculate |
Note |
---|
Don’t confuse the HTTP session that the application has with the browser with the security context or session the application creates or updates when the OAuth 2.0 flow finishes. The HTTP session exists previously, from the moment the browser accesses the Web application, and even though the end-user has not already authenticated. The security context is data on the authenticated end-user that the application usually stores in the HTTP session to remember that it is this end-user that is logged in to the application via the browser, and/or the OAuth access token. Just as the application does, TrustedX also keeps an HTTP session with the browser and a security context for the authenticated end-user. |
Example: Authorization Request
This example shows an OAuth 2.0 authorization request message from the "Portal
". The Service provider’s application requests an authorization with the "urn:lvrtc:fpeil:aa
" scope to authorization server "lvrtc-eips-as
" with condition the login page is displayed in the Latvian language.
GET /trustedx-authserver/oauth/lvrtc-eips-as?response_type=code& client_id=port%C4%81ls& state=1234567890& redirect_uri=https%3A%2F%2Fwww.demoapp.lv%2Foauth%2Fback& scope=urn%3Alvrtc%3Afpeil%3Aaa& prompt=login& ui_locales=lv HTTP/1.1 Host: eidas.eparaksts.lv
Example: Signature Authorization Request
Additional parameters to end-user authentication must be used to obtain the authorization from the end-user for generating a digital signature with a server signing identity enabled via password stored on the HSM (On signing procedure Server signing checks whatever signable data to be signed conform to data provided for signing).
If end-user is already authenticated with active SSO, end-user will have to enter signing (HSM) password only.
GET /trustedx-authserver/oauth/{as}?response_type=code& client_id=...& state=...& redirect_uri=...& scope=...& prompt=...& acr_values=...& ui_locales=...& sign_identity_id=...& digests_summary_algorithm=...& digests_summary=...
Response
Once the end-user has been authenticated (or SSO applied), and the end-user has granted authorization, the Service provider’s application receives an HTTP GET request of the following type from the end-user's browser. This HTTP request is an OAuth 2.0 authorization response or an OpenID Connect authentication response. The Service provider’s application receives this request at the redirect URL specified in the authorization or authentication request message (the redirect_uri parameter of the request) or in the registered redirect URL.
GET {redirection_uri_path}?code={code}&state={state} HTTP/1.1 Host: {redirection_uri_host}
Where {redirection_uri_host}{redirection_uri_path}
is the redirect URI to the Service provider’s application.
1 Comment
eparaksts Wiki admin
digests_summary: hex->base64->sha256->sha256->base64->url_encode digest_value: hex->base64->sha256→base64
izstrādātājam jāexpectē arī redirects ar parametru error=access_denied
lai notiktu korekts redirekts atpakaļ, ja user nospiež Cancel pie autorizācijas