Documentation

Hybrid flow

Last updated Nov 2, 2020

This article describes how to get an access token that contains the user's approval through the hybrid flow. This flow is part of the security flow.


3 readers recommend this article

Introduction

Describing how the hybrid flow works is outside the scope of this article. You should familiarize yourself with this flow by reviewing the security profile part of Open Banking that relates to the hybrid flow: Consuming PSU owned Resources from an ASPSP.

You should also familiarize yourself with this flow by reviewing the standards section on Authentication using the Hybrid Flow.

Note

Before progressing with these steps, you must have generated an account request ID or payment request ID. See Create an account request or Create a payment setup request for further information on creating these IDs.

As a TPP (Third Party Provider), you must initiate the hybrid flow in order to get an access token that contains the user's approval. This flow isn't the usual client <-> server flow, since the user must also be involved in the process. You must complete the following steps as the TPP:

  1. Generate a request parameter JWT. This JWT must contain your account request ID or payment request ID. For the remainder of this article, the generic term intent ID will be used to represent either the account request ID or payment request ID depending on which one you have.
  2. Redirect the user to the authorization endpoint.
  3. Receive the authorization code response via a call back.
  4. Exchange the authorization code for an access token.

Generate a request parameter JWT

You first need to create a JWT called the request parameter JWT in order to send an authorization request. This JWT contains all the authorization parameters. We use a JWT so it's signed and as the request goes through the user's web browser, an attacker cannot modify any of the parameters.

The way the OIDC request parameter works is outside the scope of this article. You should review the OIDC standard: Passing Request Parameters as JWTs.

Here is an example of the request parameter we used against the ForgeRock ASPSP:

eyJraWQiOiI4aF93MHJGck1xeUpuTnkyYVFUMUJEazhqZVUiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJodHRwczpcL1wvYXMuYXNwc3AuZGV2LW9iLmZvcmdlcm9jay5maW5hbmNpYWw6ODQ0M1wvb2F1dGgyXC9vcGVuYmFua2luZyIsInNjb3BlIjoiYWNjb3VudHMgb3BlbmlkIiwiY2xhaW1zIjp7ImlkX3Rva2VuIjp7ImFjciI6eyJ2YWx1ZSI6InVybjpvcGVuYmFua2luZzpwc2QyOnNjYSIsImVzc2VudGlhbCI6dHJ1ZX0sIm9wZW5iYW5raW5nX2ludGVudF9pZCI6eyJ2YWx1ZSI6IkExNGM1MmRkMi00Nzg4LTQyOWQtOWZiNy03MTAxYWViZGQ1M2IiLCJlc3NlbnRpYWwiOnRydWV9fSwidXNlcmluZm8iOnsib3BlbmJhbmtpbmdfaW50ZW50X2lkIjp7InZhbHVlIjoiQTE0YzUyZGQyLTQ3ODgtNDI5ZC05ZmI3LTcxMDFhZWJkZDUzYiIsImVzc2VudGlhbCI6dHJ1ZX19fSwiaXNzIjoiMzFiMTU1YjctNWE1Zi00ZTI4LTk4NmItNzRkM2Q2MjMwNTVmIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvZ29vZ2xlLmZyIiwic3RhdGUiOiI1YTZiMGQ3ODMyYTlmYjRmODBmMTE3MGEiLCJleHAiOjE1MTY5Njg4NTYsIm5vbmNlIjoiNWE2YjBkNzgzMmE5ZmI0ZjgwZjExNzBhIiwiaWF0IjoxNTE2OTY1MjU3LCJjbGllbnRfaWQiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJqdGkiOiI1MTk5MmRjZS1kM2NlLTRjODktYWFlOS0zYTM2MzUyODlmZTUifQ.WYZ_3IyEDTHyGhMwexqnjIJt18HmxQdlchpfV3scUaGVWYk4Fo60WHU9XY3Bdk8QGXPQqNvGVGPhdgGNlT5k4U5pH9_tZ0CEvzzcAb3UsSWohn3yEA52NzTEuIKTsTNZi3UH_S5pctkCR-ZPHHjzJE8PKc6DR_ACyYRE2m7HSmO3d5mzZcwZPvRg8WhhI91vQLXRk7Q_P35ylW0_ayLrzkiZzcYH0ntSgzPJt1nSS5udiVbajJ_vjreYSWtUaOAfbvyzkF-xkNDBdHmyyogv2QGoB_Lb7PWHFcZZK6qqFzXs0vBihjbs7gwIyjgfmog9hHDa2_kViJ1PstzrD3FCNKGogcZVYu86CsRoH0J-3sxNzOz9cuyR3tLftKFnbuAW2O9T70z4Sm7mjsKKQYAQl6v0fbzs9aH6ru6-PfA7gdT4Q3pZbWmppKBKYqcrdglBvhBJnObUV3nJFZg5jgwPubygVQfTB3jkuo00H6i-_frv9BecbCslEMgRCPiQ7lNRSC_kHlR_pG0OesldBw3EBITmZJ-RoBOCXZ_Ju0YuFOiNux_y1utWu1suWdzCSTn4HgKjpY0yrI2owvNNszdOPmbdpt_dmO8asHMW6k8vVOav2eSvL9YgNUDZeTc-OYMU8QHjrxpGYPnst1uv22R_1fhmSmFQZTgvxoQgvGveqiQ

If you decode this JWT (for example, using https://jwt.davetonge.co.uk/), you can see it contains the following information:

{ "kid": "8h_w0rFrMqyJnNy2aQT1BDk8jeU", "alg": "RS256" } { "aud": "https://as.aspsp.ob.forgerock.financial:443/oauth2/openbanking", "scope": "accounts openid", "claims": { "id_token": { "acr": { "value": "urn:openbanking:psd2:sca", "essential": true }, "openbanking_intent_id": { "value": "A14c52dd2-4788-429d-9fb7-7101aebdd53b", "essential": true } }, "userinfo": { "openbanking_intent_id": { "value": "A14c52dd2-4788-429d-9fb7-7101aebdd53b", "essential": true } } }, "iss": "31b155b7-5a5f-4e28-986b-74d3d623055f", "response_type": "code id_token", "redirect_uri": "https://google.fr", "state": "5a6b0d7832a9fb4f80f1170a", "exp": 1516968856, "nonce": "5a6b0d7832a9fb4f80f1170a", "iat": 1516965257, "client_id": "31b155b7-5a5f-4e28-986b-74d3d623055f", "jti": "51992dce-d3ce-4c89-aae9-3a3635289fe5" }

 The following table describes the key fields included in this JWT:

Claim name Description
kid The key ID must match the signing kid provided by the Open Banking directory. The ForgeRock AS reads our JWK_URIs and looks for the JWK that corresponds to this kid. Therefore, it is essential that this kid matches the correct JWK, which is why you must specify the kid of the signing key here.
alg The algorithm used for signing this JWT. Currently, only RSA can be used.

aud

The audience must match the AS issuer ID. ForgeRock's issuer ID is:

https://as.aspsp.ob.forgerock.financial/oauth2/openbanking

You can find the AS issuer ID for any bank by reading the well-known endpoint of the AS. ForgeRock's endpoint is: https://as.aspsp.ob.forgerock.financial/oauth2/.well-known/openid-configuration

scope The scope should be "openid accounts" for the account request. For the payment request, you should have an extra "payments" scope.
claims You need to add a claim "claims" inside the JWT claims. This addition allows custom claims to be defined in the "claims" section. You can then add any claims specific to Open Banking here.

acr

The Authentication context class reference is a way to specify the recommended level of authentication for the user. It is recommended that you use "urn:openbanking:psd2:sca" as this will ensure the user has to go through the Open Banking recommended level of authentication.

As a TPP, it's your duty to verify that the user actually went through this level of authentication. The OIDC standard states that an "acr" claim will be returned to you in the ID token and it will contain the ACR used during the flow. Therefore, you must verify that the "acr" value from the ID token claim matches the "acr" you set up during the hybrid flow.

openbanking_intent_id

The intent ID is a special claim defined by Open Banking, as described in the OIDC standard: Requesting Claims using the "claims" Request Parameter. You must put the account request ID or payment request ID here otherwise the ASPSP won't be able to retrieve the account or payment request.

We recommend you always set this claim in the ID token and userinfo section as this will help the ASPSP to stay compliant with the OIDC standard.

iss and client ID The iss and client ID should match. You should specify the client ID that was returned to you after you onboarded as the TPP.

You should sign this JWT using the signing key registered in the Open Banking directory. 

Redirect the user to the authorization endpoint

After you have generated the request parameter JWT, you are now ready to redirect the user to the authorization endpoint. To do this, you must construct the authorization request and redirect the user to it via a 302 redirection.

As a TPP, it's important you understand the OIDC concept behind this authorization request. You won't get a synchronous response because you redirect the user to this URI and the following step only happens between the user and the ASPSP. Once the ASPSP has completed their part, they will redirect the user back to you. They will use the redirect_uri you specified in the request parameter and will insert the information they want to transmit to you (the ID token, the authorization code and the state) in the fragment. You should then use the state to retrieve some context in order to associate this response with the corresponding request. This is discussed further in the following section: Receive the authorization code response via a call back.

Here is an example of an authorization request:

https://as.aspsp.ob.forgerock.financial:443/oauth2/realms/root/realms/openbanking/authorize?response_type=code%20id_token&client_id=31b155b7-5a5f-4e28-986b-74d3d623055f&state=5a6b0d7832a9fb4f80f1170a&nonce=5a6b0d7832a9fb4f80f1170a&scope=accounts%20openid&redirect_uri=https://google.fr&request=eyJraWQiOiI4aF93MHJGck1xeUpuTnkyYVFUMUJEazhqZVUiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJodHRwczpcL1wvYXMuYXNwc3AuZGV2LW9iLmZvcmdlcm9jay5maW5hbmNpYWw6ODQ0M1wvb2F1dGgyXC9vcGVuYmFua2luZyIsInNjb3BlIjoiYWNjb3VudHMgb3BlbmlkIiwiY2xhaW1zIjp7ImlkX3Rva2VuIjp7ImFjciI6eyJ2YWx1ZSI6InVybjpvcGVuYmFua2luZzpwc2QyOnNjYSIsImVzc2VudGlhbCI6dHJ1ZX0sIm9wZW5iYW5raW5nX2ludGVudF9pZCI6eyJ2YWx1ZSI6IkExNGM1MmRkMi00Nzg4LTQyOWQtOWZiNy03MTAxYWViZGQ1M2IiLCJlc3NlbnRpYWwiOnRydWV9fSwidXNlcmluZm8iOnsib3BlbmJhbmtpbmdfaW50ZW50X2lkIjp7InZhbHVlIjoiQTE0YzUyZGQyLTQ3ODgtNDI5ZC05ZmI3LTcxMDFhZWJkZDUzYiIsImVzc2VudGlhbCI6dHJ1ZX19fSwiaXNzIjoiMzFiMTU1YjctNWE1Zi00ZTI4LTk4NmItNzRkM2Q2MjMwNTVmIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUgaWRfdG9rZW4iLCJyZWRpcmVjdF91cmkiOiJodHRwczpcL1wvZ29vZ2xlLmZyIiwic3RhdGUiOiI1YTZiMGQ3ODMyYTlmYjRmODBmMTE3MGEiLCJleHAiOjE1MTY5Njg4NTYsIm5vbmNlIjoiNWE2YjBkNzgzMmE5ZmI0ZjgwZjExNzBhIiwiaWF0IjoxNTE2OTY1MjU3LCJjbGllbnRfaWQiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJqdGkiOiI1MTk5MmRjZS1kM2NlLTRjODktYWFlOS0zYTM2MzUyODlmZTUifQ.WYZ_3IyEDTHyGhMwexqnjIJt18HmxQdlchpfV3scUaGVWYk4Fo60WHU9XY3Bdk8QGXPQqNvGVGPhdgGNlT5k4U5pH9_tZ0CEvzzcAb3UsSWohn3yEA52NzTEuIKTsTNZi3UH_S5pctkCR-ZPHHjzJE8PKc6DR_ACyYRE2m7HSmO3d5mzZcwZPvRg8WhhI91vQLXRk7Q_P35ylW0_ayLrzkiZzcYH0ntSgzPJt1nSS5udiVbajJ_vjreYSWtUaOAfbvyzkF-xkNDBdHmyyogv2QGoB_Lb7PWHFcZZK6qqFzXs0vBihjbs7gwIyjgfmog9hHDa2_kViJ1PstzrD3FCNKGogcZVYu86CsRoH0J-3sxNzOz9cuyR3tLftKFnbuAW2O9T70z4Sm7mjsKKQYAQl6v0fbzs9aH6ru6-PfA7gdT4Q3pZbWmppKBKYqcrdglBvhBJnObUV3nJFZg5jgwPubygVQfTB3jkuo00H6i-_frv9BecbCslEMgRCPiQ7lNRSC_kHlR_pG0OesldBw3EBITmZJ-RoBOCXZ_Ju0YuFOiNux_y1utWu1suWdzCSTn4HgKjpY0yrI2owvNNszdOPmbdpt_dmO8asHMW6k8vVOav2eSvL9YgNUDZeTc-OYMU8QHjrxpGYPnst1uv22R_1fhmSmFQZTgvxoQgvGveqiQ

You can find the authorization endpoint for any ASPSP in their well-known endpoint. As a reminder, our well-known endpoint is: https://as.aspsp.ob.forgerock.financial/oauth2/.well-known/openid-configuration.

Note

Some values you set in the request parameter are repeated in the GET parameters. It is important to do this as it's a requirement in the OIDC standard.

You can use the Initiate account request in the Postman collection in the ForgeRock sample project, which triggers the code behind this example.

Receive the authorization code response via a call back

After you have redirected the user to the authorization endpoint, you will receive a response via the redirect URI. This response is actually a new request resulting from the redirection of the user by the ASPSP. As it is asynchronous, it is your responsibility to match this new request with the original authorization request. You can see an example of this code in the sample project.

Here is an example of the response received in our sample project:

https://www.google.fr/#code=e03b6939-fc0e-469e-9f83-51d7b6bda140&scope=openid%20accounts&id_token=eyJ0eXAiOiJKV1QiLCJraWQiOiJGb2w3SXBkS2VMWm16S3RDRWdpMUxEaFNJek09IiwiYWxnIjoiRVMyNTYifQ.eyJzdWIiOiJkZW1vIiwiYXVkaXRUcmFja2luZ0lkIjoiNGE4ODg2ZWUtMDIzMi00OWZmLTg4NGMtN2NhZjVlODA4YTBmLTI4OTUxIiwiaXNzIjoiaHR0cHM6Ly9hcy5hc3BzcC5kZXYtb2IuZm9yZ2Vyb2NrLmZpbmFuY2lhbDo4NDQzL29hdXRoMi9vcGVuYmFua2luZyIsInRva2VuTmFtZSI6ImlkX3Rva2VuIiwibm9uY2UiOiI1YTZiMTIzODMyYTlmYjRmODBmMTE3MGMiLCJhY3IiOiJ1cm46b3BlbmJhbmtpbmc6cHNkMjpzY2EiLCJhdWQiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJjX2hhc2giOiJldkVRZC11YXNEUUF0cnZEQmtOd0V3Iiwib3BlbmJhbmtpbmdfaW50ZW50X2lkIjoiQTk5YmQ1ODc5LWVmYzctNGU0OC1iYjQxLTM5ODE0NjYyMjE5MSIsInNfaGFzaCI6InpvVk95S3JHVDdhdHR3OU1ScV9OcUEiLCJhenAiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJhdXRoX3RpbWUiOjE1MTY5NjYxOTEsInJlYWxtIjoiL29wZW5iYW5raW5nIiwiZXhwIjoxNTE2OTcwMDY5LCJ0b2tlblR5cGUiOiJKV1RUb2tlbiIsImlhdCI6MTUxNjk2NjQ2OX0.a0mcnJ-Ypv5joJo2hGf3fZhgeHb85bAGYCPsS0fdCMgD29NwmhH0bDNXt1gH99s2SxpFZKxhHvHvWwUgjka-dw&state=5a6b123832a9fb4f80f1170c

You can extract the following values from this response:

Authorization code: e03b6939-fc0e-469e-9f83-51d7b6bda140 State: 5a6b123832a9fb4f80f1170c id_token: eyJ0eXAiOiJKV1QiLCJraWQiOiJGb2w3SXBkS2VMWm16S3RDRWdpMUxEaFNJek09IiwiYWxnIjoiRVMyNTYifQ.eyJzdWIiOiJkZW1vIiwiYXVkaXRUcmFja2luZ0lkIjoiNGE4ODg2ZWUtMDIzMi00OWZmLTg4NGMtN2NhZjVlODA4YTBmLTI4OTUxIiwiaXNzIjoiaHR0cHM6Ly9hcy5hc3BzcC5kZXYtb2IuZm9yZ2Vyb2NrLmZpbmFuY2lhbDo4NDQzL29hdXRoMi9vcGVuYmFua2luZyIsInRva2VuTmFtZSI6ImlkX3Rva2VuIiwibm9uY2UiOiI1YTZiMTIzODMyYTlmYjRmODBmMTE3MGMiLCJhY3IiOiJ1cm46b3BlbmJhbmtpbmc6cHNkMjpzY2EiLCJhdWQiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJjX2hhc2giOiJldkVRZC11YXNEUUF0cnZEQmtOd0V3Iiwib3BlbmJhbmtpbmdfaW50ZW50X2lkIjoiQTk5YmQ1ODc5LWVmYzctNGU0OC1iYjQxLTM5ODE0NjYyMjE5MSIsInNfaGFzaCI6InpvVk95S3JHVDdhdHR3OU1ScV9OcUEiLCJhenAiOiIzMWIxNTViNy01YTVmLTRlMjgtOTg2Yi03NGQzZDYyMzA1NWYiLCJhdXRoX3RpbWUiOjE1MTY5NjYxOTEsInJlYWxtIjoiL29wZW5iYW5raW5nIiwiZXhwIjoxNTE2OTcwMDY5LCJ0b2tlblR5cGUiOiJKV1RUb2tlbiIsImlhdCI6MTUxNjk2NjQ2OX0.a0mcnJ-Ypv5joJo2hGf3fZhgeHb85bAGYCPsS0fdCMgD29NwmhH0bDNXt1gH99s2SxpFZKxhHvHvWwUgjka-dw
Warning

A common issue is not noticing the difference between receiving values from the fragment and the GET parameters. The fragment is not sent to the server side by default, which means you need to have a client side script (such as JavaScript) that extracts the values and sends them to the server side. You must not exchange the authorization code from the client side. If you do this, you will pass your TPP credentials via the user's web browser, which you clearly don't want to happen. You must make sure that you send the values that are in the fragment to your TPP server side.

Exchange the authorization code for an access token

You can exchange the authorization code by following the OAuth2 standard: Access Token Request.

Note

You may notice that this information goes through a third party, the user. For security reasons, we don't want the user to access this access token. When you receive the authorization code (which provides the access token) you are required to authenticate to the ASPSP-AS. This authentication step means the ASPSP-AS can be sure that the access token is only going to the TPP. To achieve this, you call the access token endpoint using the authorization code and authenticate yourself in the same way as you did in the client credential flow.

To authenticate to the ASPSP-AS, you can either use:

  • Client Authentication JWT (recommended)
  • Client secret (Not recommended)

You use the same mechanism as you did in the Client credential flow.

Here is an example of how to exchange the authorization code using the private_key_jwt authentication method:

$ curl -X POST \ https://as.aspsp.ob.forgerock.financial/oauth2/realms/root/realms/openbanking/access_token \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'grant_type=authorization_code&code=e03b6939-fc0e-469e-9f83-51d7b6bda140&redirect_uri=https%3A%2F%2Fgoogle.fr&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=YOUR_CLIENT_AUTHENTICATION_JWT

Here is an example of the access token response from the ASPSP-AS:

eyJ0eXAiOiJKV1QiLCJ6aXAiOiJOT05FIiwia2lkIjoiRm9sN0lwZEtlTFptekt0Q0VnaTFMRGhTSXpNPSIsImFsZyI6IkVTMjU2In0.eyJzdWIiOiJkZW1vIiwiYXV0aF9sZXZlbCI6MCwiYXVkaXRUcmFja2luZ0lkIjoiZDhhNWY1ZDAtOWY2NC00Njc0LWI4MzktYjdlYjkyZTYwOTFjIiwiaXNzIjoiaHR0cHM6Ly9hcy5hc3BzcC5kZXYtb2IuZm9yZ2Vyb2NrLmZpbmFuY2lhbDo4NDQzL29hdXRoMi9vcGVuYmFua2luZyIsInRva2VuTmFtZSI6ImFjY2Vzc190b2tlbiIsInRva2VuX3R5cGUiOiJCZWFyZXIiLCJhdXRoR3JhbnRJZCI6ImRkYWEzYjI2LTdhNjEtNDJhNi1hYjBlLTk1ZGVlZDQ2ODJhZCIsIm5vbmNlIjoiNWE2YjEyMzgzMmE5ZmI0ZjgwZjExNzBjIiwiYXVkIjoiMzFiMTU1YjctNWE1Zi00ZTI4LTk4NmItNzRkM2Q2MjMwNTVmIiwibmJmIjoxNTE2OTY2NTQ1LCJncmFudF90eXBlIjoiYXV0aG9yaXphdGlvbl9jb2RlIiwic2NvcGUiOlsib3BlbmlkIiwiYWNjb3VudHMiXSwiYXV0aF90aW1lIjoxNTE2OTY2MTkxMDAwLCJjbGFpbXMiOiJ7XCJpZF90b2tlblwiOntcImFjclwiOntcInZhbHVlXCI6XCJ1cm46b3BlbmJhbmtpbmc6cHNkMjpzY2FcIixcImVzc2VudGlhbFwiOnRydWV9LFwib3BlbmJhbmtpbmdfaW50ZW50X2lkXCI6e1widmFsdWVcIjpcIkE5OWJkNTg3OS1lZmM3LTRlNDgtYmI0MS0zOTgxNDY2MjIxOTFcIixcImVzc2VudGlhbFwiOnRydWV9fSxcInVzZXJpbmZvXCI6e1wib3BlbmJhbmtpbmdfaW50ZW50X2lkXCI6e1widmFsdWVcIjpcIkE5OWJkNTg3OS1lZmM3LTRlNDgtYmI0MS0zOTgxNDY2MjIxOTFcIixcImVzc2VudGlhbFwiOnRydWV9fX0iLCJyZWFsbSI6Ii9vcGVuYmFua2luZyIsImV4cCI6MTUxNjk3MDE0NSwiaWF0IjoxNTE2OTY2NTQ1LCJleHBpcmVzX2luIjozNjAwLCJqdGkiOiIxOTZkYmMxNS1jM2Q1LTQzYzgtYTJhOS04YTQwMmMzZjAxZmUifQ.97SueHFLAw48zHE9-H1v51NBYViUj-GR03wkGzafHKL9Wfx40Ja_Lb6geSnF8XIaAk3PEOU0PS47lEvkPcv4KQ

Observe that ForgeRock ASPSP-AS uses a stateless access token, in other words, it's a JWT! You can decode this (for example, using https://jwt.davetonge.co.uk/) to reveal its contents:

{ "sub": "demo", "auth_level": 0, "auditTrackingId": "d8a5f5d0-9f64-4674-b839-b7eb92e6091c", "iss": "https://as.aspsp.dev-ob.forgerock.financial:8443/oauth2/openbanking", "tokenName": "access_token", "token_type": "Bearer", "authGrantId": "ddaa3b26-7a61-42a6-ab0e-95deed4682ad", "nonce": "5a6b123832a9fb4f80f1170c", "aud": "31b155b7-5a5f-4e28-986b-74d3d623055f", "nbf": 1516966545, "grant_type": "authorization_code", "scope": [ "openid", "accounts" ], "auth_time": 1516966191000, "claims": "{\"id_token\":{\"acr\":{\"value\":\"urn:openbanking:psd2:sca\",\"essential\":true},\"openbanking_intent_id\":{\"value\":\"A99bd5879-efc7-4e48-bb41-398146622191\",\"essential\":true}},\"userinfo\":{\"openbanking_intent_id\":{\"value\":\"A99bd5879-efc7-4e48-bb41-398146622191\",\"essential\":true}}}", "realm": "/openbanking", "exp": 1516970145, "iat": 1516966545, "expires_in": 3600, "jti": "196dbc15-c3d5-43c8-a2a9-8a402c3f01fe" }

Conclusion

After completing this flow, you will have an access token that represents user consent for account information access or payments. You can use this access token to consume the accounts API or do a payment submission depending on the request ID you started with:

The hybrid flow is the most complex flow you are likely to encounter with Open Banking; do not hesitate to read the sample code we have provided as this may help understand the details in the OIDC standard.


Copyright and Trademarks Copyright © 2020 ForgeRock, all rights reserved.