27 May , 2015
In the last post, we made it through defining the four roles represented in the four party diagram. Now we’re going to dig into the arrows that represent information flowing between the parties.
This is conceptually straightforward. The client needs to ask the resource owner for permission to access a resource. This needs to be explicit in terms of the type of access the client wants to get. For example, the client could present the resource owner with a request for read-only access to a repository of photos. How exactly does the client do this? The spec is opinionated but not demanding here. The client can communicate directly with the resource owner and still be compliant with the spec, but the preference is to use the authorization server as an intermediary. This makes sense if you think about it. The authorization server is going need to trust the authorization grant in order to issue the access token. It sure is easier to sort that out if the authorization server is actually the party issuing the authorization grant on behalf of the resource owner.
Those Authorization Grant arrows look like they’re hiding something…
The rest of the arrows are simple in concept; a request and a token that gives access to a resource.… Read more