Thinking about Client Application Configuration for OAuth2 Authorization Grant Flow

In trying to understand how to implement the OAuth2 protocol, it helps to consider what both parties have to do.  It's kind of like playing chess, after you reach a certain level, you have to consider the plans for both black and white.

If you are implementing a client, you can probably get away with just worrying about your opening, but as a server, you have to think about how clients are architected.

In the Authorization Grant flow (the subset of OAuth2 supported by SMART on FHIR), the client has three different components that need to work with the server's two endpoints.

1. The "login" component of the client provides the user's experience for interacting with the server, supporting the servers ability to request login credentials, authorization and in SMART on FHIR, patient selection UI.  
2. The application service component is responsible for taking the authorization grant (or auth code) and converting in into an access token for the remainder of the work it needs to perform.
3. Finally, the redirect URL endpoint is the piece in the middle that acts as the glue between the user interface at the front-end, and the service component under the covers.

Thinking about these three client components as three separate but coordinating components, with different sets of capabilities makes is much clearer how OAuth2 is supposed to work, or at least did for me today.

I suppose if you've actually implemented an OAuth2 client first this would be obvious.  Duh.  I'm not always smart the first time.