Reputation: 5
Let's say for example, I have an application that requests the customer_identifier claim (a Restricted Claim).
I'm wondering about this since I don't see a way to test the approval flow functionality out on Garden FI and testing out the functionality would be helpful in seeing how to handle this on the backend. Thanks!
Upvotes: 0
Views: 74
Reputation: 671
There isn't any specific way to test this in the Garden demo institution since the developer dashboard for JackHenry.Dev accounts does not have the UI necessary to set the External Application's link type to None nor does it have the ability to check/uncheck the box for User consent required.
However, the good news is that neither of those are actually necessary to test because once you hand things over to Banno for the OAuth flow, everything it does in between getting called and then calling back to your app is out of your control anyways.
- If I have my client not check the "user consent required" box shown in the integration guide, would the approval flow, including the dialog to permission a us access to that data, not appear?
Correct. If the administrator at the financial institution sets the External Application's link type to None and unchecks the box for User consent required then the user will not see the OAuth Consent experience.
- Does the approval flow kick off after you redirect your first authorization request with claims to the /oidc/auth endpoint?
Yes.
- If the information that we get from the identity token in the initial token request is all that we need, would we need to store the access token for the user in order to make sure the approval flow doesn't occur on each login?
Those are separate concepts.
The consent experience approval flow wouldn't occur on each OAuth connection unless the set of scopes or claims requested have been changed since the last time the user consented.
Access Tokens have a limited lifetime, so storing them beyond that lifetime wouldn't do much good. In that case, you would need to exchange a Refresh Token for a new Access Token, as necessary.
Hanging onto the Identity Token for authenticated information about the user is fine.
Upvotes: 0