Authorization Delegation: A financial accounts aggregation use case

I have many bank accounts. If I wanted to use a new and shiny graphing service, I have to get authorization from each banks individually. That’s a bit of nuisance. Instead of doing that, if I can instruct each banks to delegate authorization on my accounts to my Authorization server, it would simplify my life a lot.

Resource Registration Phase

Sure enough, I have to register each bank accounts at my preferred Authorization Server, but that is just one time. I have depicted it as the Resource Registration Phase in the following diagram.

Authorization Phase

What follows is the Authorization Phase. It is sometime later in my life. While I was surfing the web, I stumbled on a cool site “Grapher”. It pulls the standardized data from Financial APIs and makes a great graphical representation of my financial situation. Cool. Let’s use it.

I just tell the Grapher my AS by hitting “AS” button. (Or, I could have given my acct: URL so that it could pull the info about my AS.) The Grapher issues an authorization request saying “Hey AS, give me authorization to pull Nat’s data, wherever are banks are.” At this point, the Grapher does not know which bank I am using so it just cannot go to the Bank directly. In a usual OAuth case, you would have to start from the protected resource, in this case, Bank. However, in this use case, the Grapher is not doing it. Instead, it just tells the AS, “Nat’s Bank Data, please!”.

Then, I will be shown the dialogue: “Are you sure that you want to give Grapher your data?”([6][7]). I would say “Yup!” and clicks a button[8]. Authorization is done[9], and the Authorization Code is returned from the Authorization Endpoint to the Grapher’s Redirection Endpoint via a browser redirect ([10], [11]). Then, the Grapher sends the Authorization Code and the Client Secret to the Token Endpoint [12]. As the response, The Token Endpoint returns an Access Token and the location of the service that give it back the set of Bank API URIs and the tokens. In the diagram, this service is depicted as “Intro” standing for Introspection service. UserInfo endpoint in OpenID Connect Core is a kind of introspection point, but there can be many other types. An AS might be supporting bunch of them. Upon receiving the access token, the Grapher sends it to the Introspection Endpoint specified in the Authorization Response. The endpoint returns list of pairs of Bank API URI and Access Token. e.g.,

{
     "Norma Securities": {"endpoint":"https://norma.example.com/id/5835394","access_token": "ksj3n283dke"},
     "Lastish Fundco": {"endpoint":"https://fund.example.com/user/436922","access_token": "ksj3n283dke"},
     "Monami Card": {"endpoint":"https://monami.example.com/user/436922","access_token": "9f8sjfdnkwkgu"},
     "Bank of Astoria": {"endpoint":"https://ba.example.com/ac/8879874", "access_token": "Flsjdwgd0kw"}
 }

Get Data Phase

Now Grapher has all it needs. It just goes to the endpoints with the relevant access_token and fetch data [16]〜[19]. It would have to loop through all the banks, but that should be fine.

Service Provision Phase

Now the grapher has all the data. It hen processes the data and creates a great graph for me [20]〜[22]. From the user point of view, I have done it with only a few clicks. This is great, is it not?

 

One Reply to “Authorization Delegation: A financial accounts aggregation use case”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.