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 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.
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.
But SMART's current approach makes it extremely difficult for anyone using a commercial OAuth2 infrastructure to use their standard.
ReplyDelete