Thanks to That Person

In my first computer class, we entered our programs using a line editor, and unless we were unlucky, had a CRT to work with (although the unlucky still go stuck with the linotype).  We had a text book, some well thumbed compiler manuals on a bookshelf that were shared among the many students, and there was always, somewhere, that guy (or less often but still present, that girl), who soaked it up and knew the answers to the real tricky stuff.

As I moved into the workplace, we had CRTs still, but some had graphics capabilities, there were still tons of manuals on our shelves (and for most of us, we each had our own copy).  If you were one of the lucky ones, you got graphics.  The manuals were less well thumbed, and somewhere in the office, there was that guy (or more frequently, that gal) who knew how to find the answers.

Later, we all got to move up to 16, then 256, then 16384 colors, with 640 x 480 resolution, and then 800 x 600, and if you were one of the lucky ones, 1024 x 800 displays.  Email came to the fore. Manuals were still handy, yet there was still that person.  Sometimes they'd be in another office. You'd pick up the phone, or send them an email.  After two or three forwards and days, or more depending upon the challenge, the e-mail would come back with the answer.  And because that person had email, if they didn't know the answer, they at least knew who did.

And then came the Internet, and CD drives.  Instead of a shelf of books and a file drawer full of disks you saved because you just might need them again, there was the almighty CD.  And books were fewer.  And if you were one of the lucky ones, you had INTERNET!  And that guy or gal might be a half-continent away, and e-mail was reliable and you'd only need to way a few hours.  And he or she probably had Internet, at least at home, because they still sucked it all in, and knew where to find the answer, on the Internet, or on the CD.  Of course, you still had a drawer full of CDs, but at least it was a normal one instead of a file drawer.

Now we have StackTrace, and web sites, and volumes of data.  You can ask Google or Bing. Training is online, complete with slides and audio. that person has a blog, and a twitter account or a linked in, or all three. You no longer need to be lucky to have a laptop, though if you have a touch screen or tablet, you can probably to count yourself among the lucky.  You can read what that person has to say daily, or even listen to them or better yet watch them. That person now has fans.

I'm a fan of lot of people out there.  You know who you are.  I couldn't this person without you being that person.  Thanks.

-- Keith

Handling Extra OAuth2 Authentication Parameters

I'm deep into spec'ing out an OAuth 2 implementation, which means that I have to give all the detailed rules about what to do with parameters sent to the authorization endpoint of an OAuth2 server.  The question arose, what do we do with parameters that aren't recognized.  Fortunately, OAuth2 clearly resolves this issue for us (and for you):

In the section describing the OAuth2 Authorization endpoint, what OAuth2 says is
"The authorization server MUST ignore unrecognized request parameters."
There's a very good reason for this.  It allows profilers of OAuth2 to add parameters with additional specified behaviors.  You won't find the SMART on FHIR "launch" parameter anywhere in the OAuth2 spec. For those endpoints that do recognize it, they can do something useful with it.

The same thing works for unrecognized scopes.  If you don't recognize it, it isn't an error, just ignore it and it should go away (the application that sent it should be expected to behave correctly when it is ignored).

Postel's law rules.

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.