Replies: 1 comment
-
Hey, sorry for the late response and take this with a grain of salt, but
I think this is because it is not what you would use OAuth2 for. The one-time consent you can implement in your business logic |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello guys, I am having a problem that maybe you guys can help me with some guidance,
I am currently implementing a service that is a Facade for an OpenBanking API. In other words, we are required to provide an API that conforms to a specific OpenBanking interface.
This interface requires authorization delegation and an OpenID certified provider, that's why we chose Hydra.
The problem
Currently, the clients/users are expected to follow the normal authentication+consent flow once to get an access token with the scope
payment
, after that they will need to obtain one-time consents every time a new payment needs to be authorized.This part of the one-time consent is the part that apparently doesn't fit well with the OAuth2 flow, at least in my head.
For the first type of payment (domestic payments) I am expected to implement these 2 routes:
POST /domestic-payment-consents
: Creates a one-time consent request and returns a consent idGET /domestic-payment-consents/{ConsentId}
: at any time returns the consent status which can beAuthorised
,Rejected
orWaiting
Then later when the consent is authorized we are expected to receive this
ConsentId
along for future requests.So I was thinking that if I could just redirect the user through the authentication+consent flow for granting a
domestic-payment
scope (or something like that), and then forcing theremember_me
option to be alwaysfalse
I would obtain a one-time consent for that payment. Then I could use the context to keep information about the specific details of that payment.But still, this feels like I am doing something wrong, e.g. there is no route in Hydra for just
creating a consent
outside the OAuth2 flow, so the first route would be problematic to implement and there is also no route for retrieving the state of a consent request at anytime as I was expecting =/.Question
So far I get the impression that the correct way of doing this is by not using Hydra for this second part of the flow. But I wanted to be sure that this is indeed the case since there is so much I am still learning about OAuth2 and I would prefer to avoid making mistakes at this stage.
What do you guys think? Is there something I am missing here or indeed this does not look like something that should be done using hydra?
Beta Was this translation helpful? Give feedback.
All reactions